Improve the text representing parameter values

@messmerd is already working on this.

Since May 11, 2026.

## Enhancement Summary

The way model/parameter values are converted to text (and vice versa) is currently an inconsistent, poorly implemented mess.

A model might display "Volume: -3.5 dBFS" in its tooltip, "66.8344%" in its context menu, and "66.8" in the Automation Editor. What we want is for it to display "-3.5 dBFS" in all three situations.

Wherever possible, users should never have to see or work with raw parameter values.

## The Cause

The problem exists because value-to-text and text-to-value conversions are reimplemented in multiple places and in multiple different ways:
- `FloatModelEditorBase`
- Has highly customizable methods for getting tooltip text (`currentValueToText`/`currentValueToTextUpdate` and `getDynamicFloatingText`)
- Has method for manually entering a value (`enterValue`) which can be customized by derived classes (`VolumeKnob` for example)
- Uses description and unit strings
- `AutomatableModel`
- Has `displayValue()` which is only used in the Automation Editor
- The text is simply the scaled value converted to a string
- No description or unit string
- `AutomatableModelView`
- Converts model values (current value, initial value, and any value in the clipboard) to text for its context menu
- The text is the raw parameter value multiplied by a weird hacky "conversion factor" then converted to a string, with the units appended to the end
- Has protected description and unit strings which derived classes can use, though it only uses the unit string itself
- `Fader`/`EqFader`
- Contains some duplicate code from `FloatModelEditorBase`
- Has method for manually entering a value (`adjustByDialog`)
- Has a `modelIsLinear` parameter in the constructor which appears to allow old pre-[#7636](https://github.com/LMMS/lmms/issues/7636) float models to work correctly, though it's confusing to me
- Also uses the weird hacky "conversion factor" stuff when converting to text

All of this hacky and duplicate code leads to inconsistent and incorrect text representing a model/parameter's value.

## Implementation Details / Mockup

We need an interface in `AutomatableModel` which acts as a single source of truth for converting values to text and vice versa.

What I've done for tooltips in `FloatModelEditorBase` is a good start, but it needs some more work:
- All text/value functionality should be moved to `AutomatableModel` or at least be accessible from `AutomatableModel`
- This is needed for the Automation Editor which only has access to an `AutomatableModel`, not a `FloatModelEditorBase`
- Move `currentValueToText()` and `currentValueToTextUpdate()` to `AutomatableModel`
- Move the description and unit strings from `AutomatableModelView` to `AutomatableModel`
- All the text-related functionality could come from a "parameter interpretation" interface, and each `AutomatableModel` could keep a non-owning pointer to an implementation of that interface. When custom parameter text is needed (i.e. VST knobs, volume knobs, etc.), a custom parameter interpretation can be created and assigned to the model.
- `valueToText()` - Support converting any value to text, not just the current value
- This capability is needed in the Automation Editor (for displaying text for the parameter value at the current mouse position) and the model's context menu (for displaying text for the "Reset" option, which is the model's initial value)
- VST2 lacks native support for this in its API, so we will need a fallback option (raw parameter value or hacks)
- REAPER defines [an extension](https://www.cockos.com/reaper/sdk/vst/vst_ext.php#vst_ext) to the `effGetParamDisplay` VST2 opcode which would solve this problem for some VSTs
- Need a way to indicate whether this feature is supported. If it isn't, we can then fall back on displaying the raw parameter value as a string.
- `textToValue()` - Support converting text to values
- Used after the user manually enters a value
- Does not have to accept a number string - could be any text, depending on how the particular model implements it.
- The box for entering a new value will need some work. For example, for enum parameters, we wouldn't want the user to type out "sawtooth" - we'd want them to select "sawtooth" from a dropdown containing all the options.
- Our VST implementation will need to support parameter properties in order to detect enum parameters and other info affecting the "enter a value" box displayed to the user.
- When there is any uncertainty over whether a user-friendly implementation is possible (any chance the user would have to type a non-intuitive string or have the text-to-value conversion fail), maybe both the plugin-supplied text AND the internal model value should be presented to the user, just so they are never left high and dry.
- `FloatModelEditorBase`, `AutomatableModelView`, `Fader`, `EqFader`, etc. should all migrate to the new `valueToText()`/`textToValue()` methods in `AutomatableModel` rather than trying to do their own thing

With these changes, users would be presented with consistent and helpful text representing the values of parameters. No more discrepancies between tooltips, context menus, and Automation Editor, and users will not have to deal with meaningless raw parameter values as often.