This allows partially parsing a json object, allowing some parts to be
passed on as strings to another component that does its own parsing
(ex. a pipewire module)
The intention is to make checks for enabled log topics faster.
Every topic has its own structure that is statically defined in the file
where the logs are printed from. The structure is initialized transparently
when it is first used and it contains all the log level flags for the levels
that this topic should print messages. It is then checked on the wp_log()
macro before printing the message.
Topics from SPA/PipeWire are also handled natively, so messages are printed
directly without checking if the topic is enabled, since the PipeWire and SPA
macros do the checking themselves.
Messages coming from GLib are checked inside the handler.
An internal WpLogFields object is used to manage the state of each log
message, populating all the fields appropriately from the place they
are coming from (wp_log, spa_log, glib log), formatting the message and
then printing it. For printing to the journald, we still use the glib
message handler, converting all the needed fields to GLogField on demand.
That message handler does not do any checks for the topic or the level, so
we can just call it to send the message.
Since the string length returned by wp_spa_pod_get_data() does not always match
the size of the actual json object because it is stored in contiguous memory, we
cannot always rely on that API to get the json string data.
The new wp_spa_pod_to_string() always allocates a new string with the same
length as the json size, guaranteeing that the string returned always represents
the json object, regardless of whether it is nested or not. It is always
recommented to use wp_spa_pod_to_string() unless you know what you are doing.
