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.
with ISOLATE_ENV, it isolates the global environment between scripts
just like it did before; without it, it uses a common environment
with MINIMAL_STD, it restricts even further the available library
functions; useful for configuration files that don't need to do
actual scripting, just to define some tables
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
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
By default system-lua=false, so the bundled version is built.
The default_library for the lua subproject is also set to static
now, so that we don't need to install liblua and mess up the system.
For existing build trees, this needs to be switched manually now with
-Dlua:default_library=static (or just wipe the build dir and start clean)
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
* 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
