Move nested objects/arrays from wireplumber.settings into their own section.

Currently, nested objects or arrays in the wireplumber.settings section from the configuration cannot be merged if they are defined multiple times in different files. This is because the PipeWire configuration only allows to overwrite top level objects (sections), meaning that nested arrays and objects are completely overridden when merging sections.

I don't think defining everything in a wireplumber.settings section is a good idea for the wireplumber configuration, because users would be forced to edit the existing wireplumber configuration if they just want to add a new ALSA rule for example (or setting a ALSA/Bluez/V4L2 monitor property), instead of just dropping a new configuration file with the ALSA rule they want to add.

The idea of this MR is to move all nested objects/arrays from wireplumber.settings that cannot be changed at runtime (such as the rules and monitor properties) to their own section. For example, the monitor.alsa.rules nested array from wireplumber.settings is moved into its own wireplumber.alsa.rules top level section, the monitor.alsa.properties nested object from wireplumber.settings is moved into its own wireplumber.alsa.properties top level section, etc...

In order to do the above, a new WpConf API was added to allow users get any configuration value from any section easily. Note that the WpConf API is not a replacement for the current WpSettings API, the WpSettings is still needed as it allows subscribing callbacks when a settings has changed in the metadata at runtime.

It is important to differentiate WpConf from WpSettings. Here are the differences:

• WpConf:
  • It is not associated with any WpMetadata object.
  • It contains values that cannot be changed at runtime (Eg: rules, module dependencies and monitor properties).
  • It provides an API to easily access any value in any section of the wireplumber.conf file (even the PipeWire context.* sections). The same sections and arrays are merged if they are defined in multiple files.
  • It provides an API to easily apply rules to matching properties.
• WpSettings:
  • It is associated with a WpMetadata object (sm-settings).
  • It only contains values that can be changed at runtime (Eg: the move and follow settings from policy-node.lua)
  • It provides an API to easily subscribe callbacks when a value has changed in the metadata at runtime.
  • It does not have an API to apply rules to matching properties (this has been moved to WpConf as rules cannot be changed at runtime)
  • The module-settings is charged to select what values from the configuration are considered settings (this is the wireplumber.settings section from the configuration). This module also is charged to save and load persistent settings.

I recommend having a look at the wireplumber configuration of this MR to understand better the changes.

cc @ashoks