Fixes #20

There is no good reason to keep them private

This is an attempt to unclutter the API of WpProxy and
split functionality into smaller pieces, making it easier
to work with.

In this new class layout, we have the following classes:

- WpObject: base class for everything; handles activating
|           and deactivating "features"
|- WpProxy: base class for anything that wraps a pw_proxy;
 |          handles events from pw_proxy and nothing more
 |- WpGlobalProxy: handles integration with the registry

All the other classes derive from WpGlobalProxy. The reason
for separating WpGlobalProxy from WpProxy, though, is that
classes such as WpImplNode / WpSpaDevice can also derive from
WpProxy now, without interfacing with the registry.

All objects that come with an "info" structure and have properties
and/or params also implement the WpPipewireObject interface. This
provides the API to query properties and get/set params. Essentially,
this is implemented by all classes except WpMetadata (pw_metadata
does not have info)

This interface is implemented on each object separately, using
a private "mixin", which is a set of vfunc implementations and helper
functions (and macros) to facilitate the implementation of this interface.

A notable difference to the old WpProxy is that now features can be
deactivated, so it is possible to enable something and later disable
it again.

This commit disables modules, tests, tools, etc, to avoid growing the
patch more, while ensuring that the project compiles.

-> 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

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

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 way we can more easily distinguish different objects when
looking at the log, although it's not perfect

This allows filtering messages without a domain using WIREPLUMBER_DEBUG

This extends GLib's logging system, so it is compatible with
g_debug() and friends, but it uses a better logging format and
supports filtering debug domains with wildcards, like in gst.