next: refactor component loading to use a dependency-based system

I'm doing some more refactoring here to make component loading easier to understand and use, as well as customize.

• First, each component can now provide a "feature", which is basically a string that describes what it does. I've tried to make the feature names uniform and I plan to document the nomenclature.
• Second, features can be marked as required, optional or disabled. When a feature is associated with a component (by the use of the provides field), this marking extends to the component. required components must be loaded, otherwise the operation will fail and make wireplumber quit. optional components don't need to be loaded, unless they are marked as required dependencies (see below) of other required components. disabled components won't be loaded at all, and in case they are marked as required dependencies of something else, then the operation will fail.
• Each component can now list required dependencies that it has (required field) as well as optional dependencies (wants field). This allows pulling dependencies. When the load operation starts, only required components are considered for loading. Then, any additional optional components are pulled based on these fields.
• It's obviously fine to disable optional components that are optionally wanted by other components. This way we can customize behaviour. For instance, support.dbus is optional and it's optionally wanted by other optional modules (reserve-device and portal-permissionstore). If you set support.dbus = disabled in the config, none of these modules will be loaded without any complaints. And by default, since they are all optional, if d-bus is not available, none of these modules will be loaded without failure (just a notice in the log). This is a better approach to !503 (closed) (CC @pvir)
• By default all features are optional, which makes all components optional as well. However, if a component is not associated with a feature, then it is considered to be required. This allows backwards compatibility to the older style of just listing all the components that must be loaded. It will allow users to load custom scripts by extending this json array, without having to explicitly define features and dependencies.