ArduCopter - Parameters.h - changed initialisation order to remove compiler warning (have not changed enum values so shouldn't require eeprom format id update)

update radio packet
fix rlogs
add left/right mavlink log graphing (left/right mouse)
modify update detector.

this adds local and remote radio noise levels

AP_MotorsMatrix - fixed stability patch issue in which it would not limit a motor's output unless an opposite motor had been defined.  This would only have affected Y6 frames.

3dr Radio support
update mavlink library

3DR R
setup layout - thanks andrew.

update message definitions
fix radio screen

AP_Motors - fixed last "shadowing" compiler warning caused by badly named parameter in auto_armed method.

AP_MotorsMatrix - fixed another compiler error regarding shadowing a variable.  Fixed by removing those  the angle and direction arrays which weren't even used

AP_MotorsHeli - fixed compiler warning re move_swash function declared with int parameters in .h file but actually using int16_t in .cpp file.  They're the same in arduino but perhaps the build checker is a little more strict that Arduino.

AP_Motors - fix compiler warning re shadowing a variable caused by badly named parameter in armed function.
Another compiler warning fixed in AP_MotorsMatrix.cpp caused by declaring "i" twice.

ArduCopter - removed unused motor pde files including heli.pde, motors_hexa.pde, motors_octa.pde, motors_octa_quad.pde, motors_tri.pde and motors_y6.pde

ArduCopter - test.pde - changed references "motor_armed" to "motors.armed()" as part of move to AP_Motors library.
Change to ESC initialisation calls to use motors.throttle_pass_through method of AP_Motors class.

ArduCopter - system.pde - changed references to "motor_armed" to "motors.armed()" as part of the move to use AP_Motors library.

ArduCopter - setup.pde - changed cli for helicopter to call the new AP_Motors class's parameters instead of the global parameters.
changed init_esc to call the AP_Motor's class's "throttle_pass_through" function.

ArduCopter - radio.pde - changed motor initialisation to set update rate, frame orientation, min and max throttle to AP_Motors class.
Note: perhaps the motors speed at least should be moved to a parameter within the motors class.
output_min function greatly simplified as this is handled by the AP_Motors class.

ArduCopter - motors.pde - changed references to "motor_armed" to "motors.armed()" because we've moved to using the AP_Motors class.
Simplified set_servos_4 function which was responsible for calling "output_motors_armed" or "output_motors_disarmed" as this determination as to whether the motors are armed or not is handled within the AP_Motors class.

ArduCopter - removed references to MOT_1 etc as these are now within the AP_Motors class (i.e. MOT_1 has become AP_MOTORS_MOT_1)

ArduCopter - increased firmware version to 118.  Removed nearly all heli parameters as these are all created by the AP_MotorHeli class now.
Note: we cannot move the heli_servos to the AP_MotorHeli class yet because of a small issue in the parameters class.

ArduCopter - Log.pde - changed MOT output to dataflash to take values from AP_Motors class's motor_out array instead of the global motor_out array.

ArduCopter - GCS_Mavlink.pde - changed output to ground station to use new AP_Motor's class motors array inplace of the global "motor_out" array.

ArduCopter - Attitude.pde - moved heli_get_angle_boost from heli.pde (which will be removed) to Attitude.pde.  In fact we should combine heli_get_angle_boost and the regular get_angle_boost.

Remove global motor_filtered and motor_out arrays.
Removed all global heli variables.
replace "motor_armed" with "motors.armed()"
removed output to rc_4 for tri because this is now handled by AP_MotorsTri class

add stab kd ch6
fix mono/linux serial port list

     1. it's step towards rearchitecting the current code base ahead of a move to RTOS.
     2. internally it uses a MatrixTable for the Quad, Octa, OctaQuad, Y6 frames.
     3. it implements the missing stability patch for Octa and OctaQuads (still missing for Y6)

Later check-ins will incorporate into the main ArduCopter code.

This allows for arbitrary stream rates, and supports flow control if
you are using a 3DR radio

this makes it possible to fetch parameters with very low air data
rates

streams can now be requested at any multiple of 20ms. So if you ask
for a stream at 7Hz then you will get it at close to 7Hz.