Not really a hard requirement, wrt libpipewire API, but it's
hard to keep runtime compatibility with earlier versions when
it comes to configuration options

Plugin() is confusing because it's not a constructor, it just finds
an existing instance of a plugin object. All other camel-case
functions are constructors in the current lua API.

This is no longer used and likely not very useful now that we have
a simpler design.
We can re-add it in the future if necessary, but let's keep it out
of the 0.4 release.

Also rename the intermediate lua api table WpDebug -> WpLog

Keeps things more consistent with the function names (wp_log*),
with the lua api (Log.*) and with pipewire using log.{h,c} as well.
After all, these functions are for logging...

This is not part of the policy, it's something standalone that writes metadata

Needs to be disabled by default, since it's not built by default now

We no longer have the audiofade-related code

This is only intended to be used with specific embedded
applications. There is no good reason to use it on
a standard desktop environment.

Handles SUSPEND and RESUME wpipc requests in order to set metadata that will
eventually unlink or re-link endpoints.

Simple library that uses sockets for inter-process communication. It provides an
API to create server and client objects. Users can add custom handlers in the
server, and clients can send requests for those custom handlers.

After all, we can just load multiple lua config files/directories
from a single .conf file and so have both styles available for the
user to choose at runtime

These allow running multiple instances of wireplumber with
different config files. The config file is denoted on the service
name, ex: wireplumber@bluetooth loads bluetooth.conf

This only applies to non-device nodes, because monitorVolumes
are not exposed on device Routes

Configurable. Replaces the "flatpak" access policy.

This configuration allows splitting wireplumber into multiple instances.
The "main" instance takes care of loading and managing devices
The "policy" instance does all the linking and implements endpoints
The "bluetooth" instance runs the bluetooth devices & nodes

Test with (in separate terminals):
./wp-uninstalled.sh -c config-split -- wireplumber -c main.conf
./wp-uninstalled.sh -c config-split -- wireplumber -c policy.conf
./wp-uninstalled.sh -c config-split -- wireplumber -c bluetooth.conf

Similar to pw-uninstalled.sh, but without an interactive shell

This is not useful, we can do this on the pipewire-style config files

Also, use a context property to control whether to enable this core
or not and enable it only in the daemon

with inverted semantics

This allows configuring:
* the scripting engine, in case we ever add another one
* the app name, so that we can distinguish multiple instances
  of wireplumber
* the log level in the same way as pipewire
* wireplumber components to load. This allows loading components
  even without a scripting engine (for a mimimal daemon) and also
  allows configuring which lua config file(s) to load
* additional pw_context properties that pipewire modules may be using
* the exact pipewire modules to load (instead of relying on client.conf)

And don't override PIPEWIRE_DEBUG, unless WIREPLUMBER_DEBUG is set.
This allows pipewire to use log.level as well to set up its logging.

If WIREPLUMBER_DEBUG is set, though, override PIPEWIRE_DEBUG to prevent
log.level from being used.