- make it a GObject so that it can emit its own signals
and so that it can be shared between multiple proxies
- share the WpProps instance between endpoints, endpoint-streams
and their underlying nodes
- introduce the concept of the caching mode that redirects _set
to _set_param of the proxy that actually has the props; this allows
shared WpProps to actually set changes on the correct proxy
in a transparent way
- change methods to consume the ref of the pod and reflect that
also on wp_proxy_set_prop()
- refactor the export process on endpoints & endpoint-streams
so that they always get all the required features (info, props, bound)
and make it async so that we can take time to prepare the underlying
node to have FEATURE_PROPS
- update the props & endpoint unit tests, bringing back all the
checks that the endpoint unit test used to have

* Use a direction instead of a string prop id
* Emit default-endpoint-changed again
* Get rid of the useless virtual methods

+ rename FEATURE_CONTROLS to FEATURE_PROPS
+ add accessor for the standard spa_param_info (info->params)
+ hide the low-level params API that nobody uses

-> wp_trace_boxed (WP_TYPE_SPA_POD, pod, "some message");

by using G_TYPE_NONE (== 1), we can pass this in the log handler
to point out the fact that we expected something but it's null

As a bonus, a null object always gets printed in red because that's
the first color in object_colors

+ use a more correct naming scheme to match the one from Spa
+ remove the default video source, since we now use a different
 session for video

This makes WIREPLUMBER_DEBUG behave just like PIPEWIRE_DEBUG.
Same levels, same syntax, easier for users.

ERROR & CRITICAL are always printed, as they should; there is no point
in disabling them, since:
- ERRORs are always fatal and should never ever happen
- CRITICALs are assertion failures and indicate bugs that need to be fixed

* use a short level name, like pipewire does
* color the timestamp to compensate for the loss of the visible level name
* use 18 chars for the category

libpipewire already prints this, so we get it duplicated on the log

This happens when the daemon fails to connect and the
not installed object managers try to get installed, but
the weak ref to the core is already gone

object managers that are registered a bit early (such as the one in
wireplumber-cli) have no use if they are declared as installed before
any globals appear. After the initial registry startup, there should
be at least 1 global, the core (id=0), so even if this client has
no access to any object, the object manager should be able to
finish its installation successfully

Features are flags, therefore we must NEVER use them without a shift,
otherwise bad mistakes happen, like the previous mistake of declaring
WP_SESSION_FEATURE_LINKS as the number after WP_SESSION_FEATURE_ENDPOINTS,
which ended up being (WP_SESSION_FEATURE_ENDPOINTS | WP_PROXY_FEATURE_PW_PROXY)
and it was always becoming available together with the ENDPOINTS feature.

This serves as a base class for daemon plugins, which are implemented
inside modules

And also provide a way to disable this integration at runtime to
get pipewire's log back, with WIREPLUMBER_NO_PW_LOG=1

The GLib error level is fatal, but pipewire doesn't use it that way.
Also, the GLib critical level is meant only for programming errors
(assertions) and not for runtime errors. warn & msg levels really
fit well with the error & warn, as they are being used in pipewire
currently.

It is a valid use case to do things like call wp_session_item_export()
from within the async ready callback of _activate(), and it's not
possible unless the ACTIVATING flag has been cleared first.

To do this, use a GCClosure to wrap the callback and install marshal
guards, which are called before and after the callback, to modify
the flags.

This aligns better with the general design of consuming property
objects on constructors, both in PipeWire and WirePlumber APIs

We can now call wp_proxy_request_destroy() on endpoint links and
the WpImplEndpointLink together with the session item that created
it will be cleaned up

When a pw_global is removed on the server (by pw_registry_destroy() or other
means), it triggers the proxy removed & the registry global_remove callbacks,
but it does not necessarily destroy the pw_proxy.

For client proxies, we were previously destroying them by unrefing the WpProxy
in wp_global_rm_flags(), since the global was not "owned" by the WpProxy.

For impl proxies, we were not doing anything, as we expected that it would
only be removed from the registry if the local WpProxy was destroyed first.
This is not always the case, though, as the server or another client may
request to destroy this proxy with pw_registry_destroy()

Now we always destroy the pw_proxy as soon as it is removed from the registry,
no matter if it was a client or an impl proxy. If it was an impl proxy,
the WpProxy will continue to live and it's up to the code that created it
to handle the "pw-proxy-destroyed" signal and do something meaningful.
If it was a client proxy, the global will still unref the WpProxy right after
destroying the pw_proxy and there is no change in behavior.

Useful to destroy links and endpoint-links