Improved user control architecture

This is a rebase of #412 onto next which was previously discussed here https://groups.google.com/forum/#!topic/phoenixpilot/xbE3ws3DzUc

The main task essentially allocates control out to various submodules:
- transmitter
- tablet
- failsafe

The transmitter submodule is the ultimate authority right now, but in the future that may change when we want to support flying out of TX range (not advised right now).  The transmitter switch can also define a position "TabletControl" which passes control to the tablet module and is demonstrated here:

https://vimeo.com/63529694

When the channels go out of bound control is passed to the failsafe module.  The current implementation is to set the throttle to zero and enter stabilized mode.  This is the same as the existing code but implemented in a more principled manner.  The goal is that the failsafe module can easily be extended to more complete control schemes such as RTH for X seconds, land, etc.  Passing control to failsafe _does not_ disarm the system as this creates major problems for temporary control glitches.

I have been flying this code exclusively for the last two months and had no issues, and improved from the previous code - no flyaways.  In every mode I have tested, turning off the transmitter reliably turns off the motor and turning the transmitter back on quickly brings it back.

For planes we should leverage this to make the default failsafe behavior one of the standard crash positions (e.g. slight yaw, dive).  I read somewhere there are recommendations for some of the autonomous vehicle competitions about how to bring it down in a certain radius (for fixed height).  However, that is outside the scope of this review which preserves the existing behavior on that respect.