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