Rework Params trait API with Arc instead of Pin

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.

plugins/examples/gain/src/lib.rs

@@ -1,9 +1,9 @@
 use nih_plug::prelude::*;
 use parking_lot::RwLock;
-use std::pin::Pin;
+use std::sync::Arc;
 
 struct Gain {
-    params: Pin<Box<GainParams>>,
+    params: Arc<GainParams>,
 }
 
 /// The [`Params`] derive macro gathers all of the information needed for the wrapepr to know about
@@ -48,7 +48,7 @@ struct SubSubParams {
 impl Default for Gain {
     fn default() -> Self {
         Self {
-            params: Box::pin(GainParams::default()),
+            params: Arc::new(GainParams::default()),
         }
     }
 }
@@ -111,8 +111,8 @@ impl Plugin for Gain {
     // splits.
     const SAMPLE_ACCURATE_AUTOMATION: bool = true;
 
-    fn params(&self) -> Pin<&dyn Params> {
-        self.params.as_ref()
+    fn params(&self) -> Arc<dyn Params> {
+        self.params.clone()
     }
 
     fn accepts_bus_config(&self, config: &BusConfig) -> bool {