Remove use of rcmap library

[peterbarker]

This is built on several the modeswitch-to-rcinput PR, #8170

There is still more to do to make everything nicely orthogonal, most notably the handling of RC6 specially in terms of deadzone handling, and the setting of ranges on only a selection of the auxillary channels.

The initialising of the ranges should probably be done based on the channel option assigned as part of init_aux_function() or init_aux_functions(). We should also rename that function given we're using it for the primary vehicle RC inputs!

One of the more interesting bits in here is the forcing of the 4 primary input channels to be defined. At the moment if you set RCMAP_THROTTLE to 89 and reboot your vehicle will have to wipe its parameters to make it functional again; we use these four channels pointers trustingly throughout the code. This force-setting is only one solution to the problem; we could also drop into something like the "you have a sensor problem" loop which BoardConfig has, or we could use a dummy RC_Channel and tell the user to fix things. Or we could check for nullptr here, there and everywhere.

Also of interest is the positioning of the throttle channel in the RC_Channels base class. Every vehicle has a throttle (coughAntennaTrackercough) - does it make sense to be in the base class? @WickedShell has been working on failsafes - would it help if it was? I'm currently leaning towards putting it back into RC_Channels_Copter.

Also not done is parameter conversion. PRs very welcome ;-)

[peterbarker]

Still need to do parameter conversion.

[Naterater]

Looking for this so that #685 can be closed.

[OXINARF]

As pointed below it's still missing param conversion.

[davidbuzz]

'convert_rcmap_parameters' - seems to have parameter conversion code now.... :-) I think Peter's gonna have to tell us how ready he thinks it is now... ?

[rmackay9]

I guess you've inspected each place we use the new find_channel_for_option() to be sure it checks for nullptr?

[peterbarker]

This is actually an existing problem with the codebase; if you set a bad value in rcmap you're not going to go anywhere until you wipe your parameters by uploading a different vehicle. I've just checked in SITL, and it certainly behaves that way. This is because radio.cpp just unconditionaly sets the pointers from the rcmap values and nobody wants to check those RC channel pointers for nullptr every time they're looked at!

I don't think this PR makes the problem worse, except that the RCn_OPTIONS are much more in-your-face as a user.

I think we should address the problem, but it's a little tricky as we like to be able to reset RCn_OPTION parameters and have them generally start to work. And certainly want that behaviour for RC input channels IMO!

So what I propose is that we only update the RC input channel pointers when disarmed, and if they do go to nullptr then go to the config error loop. And for always-armed planes/rovers/trackers we do the assignments exactly once while armed.

[rmackay9]

We should check that Mission Planner's RC calibration page is OK after this. I could probably do that.

[peterbarker]

We should check that Mission Planner's RC calibration page is OK after this. I could probably do that.

It's not - I've created this branch which compiled, but I haven't tested the created artifacts yet

https://github.com/ArduPilot/MissionPlanner/compare/master...peterbarker:MissionPlanner:die-rcmap-die?expand=1