With this the basic IComponent interface is fully implemented. Next will
be `IAudioProcessor` and `IConnectionPoint` as additions to IComponent.
We'll use the same `known_iids` mechanism as used in the plugin factory.
Directly serializing and deserializing into objects was and more
boilerplate heavy (since we now need two implementations even though we
only use one), and also much less flexible because we can't wrap
payloads in structs or provide optional values that way.
This is less likely to clash with names used by interfaces and it's a
bit clearer what's going on (since they are basically proxies for
constructors and destructors).
Since the object cleans up after itself after the smart pointers are
dropped on the host side this would result in a use after free by the
smart pointers.
This now takes a regular overloaded function and the visiting is done in
`receive_messages()` itself. This way we can use templates to ensure
that the return type is correct. Otherwise auto will cause issues in the
future when we want to return multiple concrete types from a function
that takes a single variant. The alternative would be both receiving a
variant as a parameter and then returning another variant as a result,
but that is much less type safe.
- Now allows direct deserialization into existing objects. This will be
necessary for our VST3 implementations since the interface instances
we'll deserialize into will not be trivially constructable because
they have to be able to do callbacks.
- `ControlResponse` and `CallbackResponse` were dropped. These response
enums are not necessary because of the `T::Response` associated type
and returning the types directly makes the direct deserialization
possible.
And add separate implementations for the native plugin and the Wine
plugin host. This way we can easily allow the native host to do
callbacks without having to manage a load of lambdas.
Robbert van der Helm