The Dbus device reservation has been moved into a separate module, and has also
been refactored to allow reserving a device name before an actual device is
created. Devices now are created and destroyed by the monitor depending on
whether PipeWire owns the device or not. This also simplifies a lot the device
activation module to always enable devices when they are created, and never
worry about checking whether a device is acquired by PipeWire or not.

Allows implementing device specific endpoint creation logic, which is currently
needed for bluetooth endpoints as they need to be created differenly.

* add library.name to not require adding `add-spa-lib` in pipewire.conf
  or wireplumber.conf for this to work
* add a commented local=true; it can be useful to run those nodes
  locally for testing, sometimes

if there was a remainder in the buffer from a previous iteration,
make sure not to fill too much data and go past the end of the buffer

after consuming the whole buffer, cur & linestart need to
be reset to point back to the beginning of the local buffer

and add the non-disabled filenames in .gitignore so that I can maintain
symlinks to enable them without commiting them

This is out-of-date and we don't need it in fact... the default
configuration can serve as a good starting point for any custom embedded
use case.

if there is a usb device plugged, we can assume it's meant to be used
instead of the built-in audio

jack has the highest prio because if it's present, we assume the
user wants to use jack to route everything

bluez has higher prio than alsa because if it's present, we assume
the user wants to use the bluetooth device

- because it conflicts with pulseaudio and we actually still want
  pipewire to be able to run along pulseaudio on default setups
- and because it doesn't work well yet

replace them with spaces so that the GVariant parser ignores them

if jack is running, that probably means that we want the jack
endpoints to be the default playback/capture path

This module suspends a node if idle for at least 3 seconds

Disconnecting core finishes all pending tasks, which is needed in order to avoid
possible leaks if some tasks are still pending when exiting.

the on_sessions_exported callback runs from within the context
of export_tmp_globals in object-manager.c and when plugins register
more object managers, it modifies the object managers list that
export_tmp_globals is iterating over, making things behave really weird