This can now be used for most common use cases where you previously had
to do a manual `Params` implementation, like arrays of parameter objects
and duplicate parameter objects.
This is a breaking change requiring a small change to plugin
implementations.
The reason why `Pin<&dyn Params>` was used was more as a hint to
indicate that the object must last for the plugin's lifetime, but `Pin`
doesn't enforce that. It also makes the APIs a lot more awkward.
Requiring the use of `Arc` fixes the following problems:
- When storing the params object in the wrapper, the `ParamPtr`s are
guaranteed to be stable.
- This makes it possible to access the `Params` object without acquiring
a lock on the plugin, this is very important for implementing
plugin-side preset management.
- It enforces immutability on the `Params` object.
- And of course the API is much nicer without a bunch of unsafe code to
work around Pin's limitations.
This now is a single vector with all of the information in the correct
order instead of the hashmaps and a vector. This avoids deduplication,
and it especially makes manual `Params` implementations a lot more
convenient since you can't mess up with mismatching IDs between the
methods.
To accommodate exactly this, the persistent fields methods also have a
default implementation and the trait has been marked as `unsafe` since
it's the programmer's responsibility to make sure these `ParamPtr`s will
remain valid.
This may hurt performance in generic UIs a bit, but it will allow you to
programatically generate custom Params implementations for repeated
Parameters structs.
