Commander: Separate out manual control setpoint processing

[MaEtUgR]

Describe problem/solution in this pull request
New ManualControl class for handling manual_control_setpoint (and later switches) holding subscription, parameters and state necessary. It handles in this pr RC loss, RC override, RC arming/disarming.

• RC override: option to ignore throttle stick
• RC override: based on change (not centered stick)
• RC arming: based on Hysteresis instead of "loop ticker"
• RC arming: simplify the logic
• manual_control_setpoint message

Note: This is the first stab at it and I'd like to do incremental steps to not create a non-understandable monster pr.

Test data / coverage
I tested the different cases during development but will do a final pass testing all the things with this state.

Additional context
Follow up after being in the loop from reviewing #16266 and doing work on RC override.

[MaEtUgR]

As a response to @dagar 's feedback:

looks like a good direction
my only initial suggestion/question is if we can get to the point where it's more event driven so that as much code as possible is only ever executed as a result of manual_control_setpoint updating

I prepared to gate all this processing on manual_control_setpoint updates:
throttle-stick-override-upstream...rc-handling
Testing necessary but then we can add it as well.

[MaEtUgR]

Arming/disarming not working as expected on a vehicle without props. Debugging.

[MaEtUgR]

I found the issue: ebbc098
Ready for review. I'll keep on testing and will only put bug fixes on top if necessary. Arming, disarming using all methods works.

[MaEtUgR]

Found another issue: Real-world RC seems to bounce RC loss, not reproducible on master or in SITL.

[MaEtUgR]

Fixed, squashed and rebased.

[julianoes]

Couple of comments but overall that's a very nice cleanup, exactly the sort of thing we should do step by step.

[julianoes]

Why not enum class?

[MaEtUgR]

It gets used in combination with a "bitwise and" not in a direct comparison because the parameter is a bitfield. Would you define the bitwise and operator in the class or how can it be done more easily?

That's probably also why it was added in this way:
https://github.com/PX4/PX4-Autopilot/pull/13618/files#diff-33729b6612e70db2803e6b18b64a47c71e70eaf1d6b69fd233a34b3b0408a806R261

[julianoes]

I'm not super happy with the name update() for something that also returns something but I also don't have a better suggestion, unless maybe couldUpdate() or tryUpdate()?

[MaEtUgR]

I thought about this because I also don't like if everything is called update() for e.g. text search reasons. But updated() is wrong because it actually does something and I couldn't come up with something better. Maybe checkUpdateAndProcess()? Seems clunky and doesn't really help does it?

[julianoes]

Thanks for the fixes @MaEtUgR!

[MaEtUgR]

Thank you for the reviews @julianoes and @bresch and @JonasVautherin, that really helped a lot. I'll follow up with further improvements like freeing commander from the rc_found_once logic, doing all the processing in the process() function, separating arming methods.