We have ended up not using them, so let's not carry them
in the ABI of 0.4
We can always revert that, but let's first decide how
these objects should be used
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.
It is inevitable to avoid setting PIPEWIRE_DEBUG, because the
log.level from client.conf will kick in and change the pipewire log
level when the pw_context is created. PIPEWIRE_DEBUG is the only
way to override.
* 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
