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

the on_sessions_exported callback runs from within the context
of export_tmp_globals in object-manager.c and when plugins register
more object managers, it modifies the object managers list that
export_tmp_globals is iterating over, making things behave really weird

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.

This is mostly useful when using the adapter with audiotestsrc,
which supports an infinite number of channels. By specifying
a preference, we can limit it to the number of channels that we want.

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.