joystick: add "reverse" mode and "gain" functionality

[ES-Alexander]

Based over #2476¹ and #2478 (the first two commits) - I figured it would be easier to review them separately and rebase this over master before it gets reviewed. If not, we can just review and merge this one instead of those 🤷‍♂️

Fixes #2221, by adding a base reverse data-lake variable (which can be used to trigger additional related functionality), then splitting that into per-axis compound variables*. The base variable can be directly (momentarily) controlled by a joystick button, or statefully controlled with the provided Actions.

*NOTE: Since we tend to operate with the vertical axis in earth frame, the vertical axis never gets reversed, and because of that yaw shouldn't either. Motion axes vs manual control axes are also inconsistent between vehicles, so:
- ArduSub should reverse everything except Z and R
- Rover/boat should reverse only Z
- Copter should reverse only X and Y
- Plane should ignore reverse inputs (it's not safe)

Fixes #2480, with a base gain data-lake variable, and applying it by default to only translation axes (a suggestion from @Williangalvani) for each vehicle type, falling back to a gain of 1 for rotation / undefined axes. The base variable can be directly controlled with range input widgets (like a slider), or incremented and decremented with the provided Actions. Unlike the reversing state, the gain state and number of steps are persistent across reboots.

Footnotes

1. If you've been testing joystick: migrate MANUAL_CONTROL axes to data lake #2476, you'll need to delete the Axis * Output compound variables before this one will work, since it doesn't currently include a migration. ↩

[ES-Alexander]

I've just raised #2480, and realised this is probably the ideal place to implement that, because then both can be made available simultaneously (and these definitions will likely be hard/annoying to migrate for users once they already have them). Implementing both gain and reversing in a single compound variable would also be marginally more performant, because then the output messages only need to pull in one "scale" variable value.