This allows us to load the scripts from the config file without
WpCore being connected yet. We can later activate the lua-scripting
plugin at the right moment to start processing the scripts.

also, add support for loading lua config files, denoted by the
"config/lua" component type

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

This one offers API to interract on a lower level with
the D-Bus reservation API and uses GDBus high level bindings only.

Also, this one implements the full Acquire procedure, calling
RequestRelease() on the peer and requesting the name again with
REPLACE_EXISTING

deactivate() is normally called from WpCore's dispose() and
that's too late to convert a weak WpCore ref to a strong one,
so we cannot find the WpConfiguration and remove the engine.
So, keep a reference to the WpConfiguration earlier.

If the engine is not stopped on time, proxies on the export_core
are destroyed after their core and pipewire complains

WpDevice, WpSpaDevice, WpNode, WpImplNode, WpObject and object features

port module-monitor to follow the changes

Use the unused 'K' format letter in the varargs builder & parser methods

* Use a more complete API to introspect SPA types
* Avoid the need for the Tables enumeration; the tables
  are now registered with a string
* Avoid the need for initialization, work directly on spa_types
  and other static data
* Allow working with Object pods that are not Params;
  the PARAMS table was previously hardcoded in the pod implementation
* Add a different dynamic type registration system, closer to
  how spa type works. The only regression is that we can no longer
  register additional custom object fields (custom SPA_PROP_* for example),
  but this feature can be re-added later

... and make WpIterator Lua-friendly so that it can be used
with the generic for loop

Fixes #20

a module that allows loading and executing Lua
scripts from a configured directory

Now the WpPipewireObject interface is directly implemented by the mixin
and there is another interface that users of the mixin must implement
in order for the mixin to work proprely.

A lot of manual stuff that proxy classes had to do before are now
in the mixin. Also most of the data that would normally reside in Private
structures is now in the mixin data structure (stored as qdata on the object).
This is achieving the best amount of code reuse so far.

For impl objects (WpImpl*) there are also default implementations of the
standard pipewire object methods and the INFO & PARAM_* features are
more coherently enabled during the whole lifetime of these objects.

A callback is required, NULL is not accepted by GCClosure

Disable m-session-settings for now, as it needs further work

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.