This allows registering arbitrary objects on the core's registry and
finding them later, without having to add API for each and every object.
I think this is useful enough to have it public, even though it's
probably not going to be used that much... The rationale here is to
allow registering custom component loaders without having to make them
subclass WpPlugin or to create custom API for registering component
loaders specifically.
Also, remove the wp_plugin_register() and wp_si_factory_register()
functions, since they are not going to be used much in the future.
The idea is to let the component loader do the registration under the
scenes, as the component is getting loaded.
Aim for 8 pointers on each struct, wich exceptions:
- 12 pointers for already crowded/important ones
- 4 pointers for empty ones that are used for proxies; we are
unlikely to add any virtual methods on these classes ever
* use the activate/deactivate system from WpObject,
which allows async activation and error reporting
* drop 'module' property, use 'core' from WpObject
After discussing things at the AGL May 2019 F2F meeting
and reflecting on the initial design of WirePlumber,
it became clear that it needed a fresh start.