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.

Initialize the log level with WIREPLUMBER_DEBUG in wp_init()

This allows the channelVolumes and mute props to affect the output
of the null sink's monitor ports. This way we will be able to use
channelVolumes to track the configured volume of the endpoint
and the monitorVolumes to implement volume ducking.

This fixes adjusting volume for bluetooth nodes.
Previously, the spa device would request a software volume change
that we did not handle because WpImplNode was not a WpPipewireObject
and there was no way to set the Props param on it.

These don't make much sense here. In the endpoint policy we want
the clients to be linked to the endpoint that matches their role
and never move.

Also, endpoint priorities are useless. If no endpoint matches the
role, then just ignore the client.

This allows closures to be properly unrefed when they are no longer
used instead of staying alive until wireplumber exits

Because GClosure has no weak references, we are now sharing the
GPtrArray that holds these references among all the active closures
and each closure is responsible for removing itself from the array
when it is finalized. The lua engine holds a reference to a "store"
object that also has a pointer to the array and when this "store"
is finalized, all closures are invalidated and removed. Even if they
stay alive afterwards, they are only holding a ref to an empty array

This script takes links that are created by policy-endpoint-client
and activates only the ones that should be active based on role
priorities

Useful to tag objects with their creation time

As with endpoint streams, there is not much use for endpoint links
in this updated design. This will be re-evaluated.

Instead of adding Props on endpoints again and syncing with the associated
node, it is easier to just use the volume controls of the associated node

This is mainly for security reasons. This way, we can limit the
permissions of wpexec without limiting wireplumber, for instance
with pipewire's default module-access, which limits apps based on
their executable name

Links between endpoints and device nodes are done externally in LUA

This is also what pulseaudio uses, so now the volumes in wpctl match what
pulseaudio tools report and they make a lot more sense from the user's POV

* Fixes set-volume & set-mute
* Re-enables volume & mute status printout for audio nodes

and optimize a little bit so that can stop iterating params
as soon as the info is known