Feature: Improve add-on init dispatch

Handle different add-on `init()` signatures in a generic and type safe way. An adapter is selected at compile-time based on the signature of the init function. The adapter is stored in the module struct. At run-time the adapter unpacks the users init function and provides the requested arguments.

This is related to #8802.
Nope, it can't. Not in its current form. `priv` has to be a _compile-time constant_ (string literal, function pointer), because it is used to initialize the struct in file scope. Passing a compile-time constant this way makes no sense at all. It just removes the type information by passing it as `void*`. It just is not possible to do something interesting like `new PrivateBackendSingleton()`.

Now suppose we'd change the API. Suppose we'd make `priv` an output parameter. The init function now can do something like this:

````
*priv = new PrivateBackendSingleton();
````

Currently there is no way to ever access that `priv` thing ever again. Again, we could change that. However, providing a module wide singleton _without any locking_ seems like asking for trouble (think isolates). If an add-on needs a static memory location it is way better to just _declare one_, keep the type information and handle any locking issues on the add-on side.

I _really_ thought about this for a while. I can not find any use-case for the current thing at all. Anything we could do to improve the service is either outright dangerous or at least non of our business. That's why I went ahead and removed it.