Sub:correct operation of pilot input and rc failsafes

[Hwurzburg]

Pilot input failsafes historically forced RC overrides, which clears itself and leads to repeated re-entries. (BUG)

With the addition of RC failsafe,if Pilot input failsafe(no rc, no manual control or rc override MAVLink messages) is also enabled, this leads to cycling RC failsafe clears and enters (in addition to the repeating Pilot input failsafe) .

The main issue was that pilot input failsafe sets RC overrides (clearing the pilot input failsafe) instead of just setting the channel RC values to trim like other vehicles do in RC failsafe. This PR fixes the set_neutral_controls function to not use rc overrides, but directly set the channel value to the trim value (this also allows unidirectional motors to be used)

the WARN ONLY RC failsafe action was slightly modified to not only warn and prevent arming, but also force the channels values to trim when RC fails to prevent last RC values from continuing to be used after loss of RC(swim aways)....

tested in SITL...behave much more rationally now and RC failsafe + Pilot Input failsafe now works so you could use RC AND joystick reasonably.

[peterbarker]

While Plane does this, and it kind-of-sort-of is a belt-and-braces approach, I'm not actually a huge fan.

What problems were caused by these values not being set to neutral? The correct fix is usually to check that rc has_valid_input() before using it. This also has the advantage of not using bind-time values while the receiver is glitching between have-signal and no-signal from the transmitter.

[Hwurzburg]

what is neutral? it depends on type of motor and setup....bi dir motors have no output at around 1500us, but is adjusted with channel trim if needed...unidirectionals at around 1000 to 1100, again trim sets no output...

sub historically had NO rc, and pilot input came from either RC overrides or MANUAL command messages...trying to fix the problem when RC is added with minimal changes