Replaces the old create-session wireplumber.conf commands

* load config from a lua script
* use a WpTransition to organize the code
* activate plugins before lua scripts
* cleanup

The component loader is a more generic and extensible mechanism
of loading components; modules are one type of component...
The idea is to make scripts and config files also be components,
loaded by plugins that inherit WpComponentLoader

* use the activate/deactivate system from WpObject,
  which allows async activation and error reporting
* drop 'module' property, use 'core' from WpObject

+ their configuration
+ their unit tests

A new desktop profile without endpoints will be added.
The goal is to be compatible with media-session in the short term

Still missing a way to get the default endpoints, but this
is going to change and use the metadata API

Fixes #22

Fixes #20

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