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

It's not well-defined; we'll come back to that later

- Use similar code for consistency
- Add changed signals everywhere
- Port to the new object-manager API

signal handlers expect FEATURE_BOUND to be set