This is needed to be able to support modulation events in CLAP. There an
offset gets applied to the parameter's actual current value. That way
GUIs don't have to move around when parameters are being modulated and
save states cannot get influenced by modulation.
Direct initialization was no longer recommended anyways since now you
need to keep the default value in sync. The next couple of commits will
add a normalized value field and two more fields to help with
modulation.
This method is a bit more efficient than converting the string to a
normalized value and then setting the parameter using that but it's not
used right now and it adds a form of redundancy.
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.
