They are now two separate types with slightly different options. I had
these merged initially because they're 95% the same, and I thought it
would be fun to have weird distributions for integer parameters, but
that doesn't really work because hosts and the plugin APIs expect the
steps to be linear. And if you're going to have an unstepped integer
parameter, might as well use FloatParam with rounding.
Because non-linear ranges are no longer possible with IntParam, the
types have been split up to make everything much more readable instead
of adding a parameterizing the range type with another type family.
Now it no longer needs to do any unsound type punning. The internal
parameter that the wrapper has access to has been completely type
erased, and only the outer parameter knows about enum T. This also gets
rid of strum and replaces it with a custom trait.
This makes the API much, much nicer (especially consuming the egui
wrapper), and it also avoids having to lock the plugin instance which is
obviously very bad if the plugin is also supposed to be processing audio
on another thread.
These atomics make things more difficult and they don't solve the main
problem: storing the parameter objects in an easy to use struct while
still allowing hash based access to them from the plugin wrapper. Going
through this new Params trait makes a lot more sense, and with pinning
this should be safe.
