Use the new approach for creating 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.

src/common/serialization/vst3/README.md

@@ -3,12 +3,6 @@
 TODO: Once this is more fleshed out, move this document to `docs/`, and perhaps
 replace this readme with a link to that document.
 
-TODO: There are now two approaches in use: the factory takes an interface
-pointer for serialization and deserializes into an object directly, and the
-component uses an args struct because the alternative involving pointers is just
-too unsafe (as we also have to communicate additional payload data). This should
-probably be unified into only using the latter appraoch.
-
 The VST3 SDK uses an architecture where every object inherits from an interface,
 and every interface inherits from `FUnknown` which offers a dynamic casting
 interface through `queryInterface()`. Every interface gets a unique identifier.
@@ -30,6 +24,11 @@ Yabridge's serialization and communication model for VST3 is thus a lot more
 complicated than for VST2 since all of these objects are loosely coupled and are
 instantiated and managed by the host. The model works as follows:
 
+TODO: This is now slightly out of date. Instead of serializing and deserializing
+directly into interface implementations through references, we now only pass
+structs with payload data around to make the receiving process much more
+flexible.
+
 1. For an interface `IFoo`, we provide a possibly abstract implementation called
    `YaFoo`.
 2. This class has a constructor that takes an `IPtr<IFoo>` interface pointer and