Adding enum field to int types that are linked with an enum
pymavlink: support param() method for .bin and .log files

useful in mavextra.py
Plot PX4 flight modes as background colors
mavgraph: add pylab.draw()

apparently this is needed on MacOS, and doesn't seem to do any harm on
Linux, so applied

Thanks to Lorenz for this
Corrected indentation in mavwp.py.
Added __init__.py files for the tools and examples folders.
This means that  can now be run if pymavlink is on the system path.
Tools: Added CSV and JSON output to mavlogdump.py.
Updated .gitignore.
Python decoder. Added array support.

Now generated python code can successfully decode message containing
array(s) of standard C type. One drawback - only char[] fields decode as
python string, but uint8_t[] decode as python list. As I know there are no
mixing of uint8_t/char in common.xml so it is not a problem. Pull
request also contain tests for array handling. I can not find where
to place pythonic tests so I have placed them in pymavlink/tools dir.
Merge pull request #128 from johnboiles/johnb_enum

Adding optional enum attribute to fields that represent an enum
pymavlink: cope with bad data at and of log
pymavlink: fixed mode mapping for copter/rover
pymavlink: fixed waypoint saving

last indentation fix broke the logic
pymavlink: fixed mavflighttime for DF logs
pymavlink: calculate distance as well as time in mavflighttime.py
common.xml: added AHRS health status bit

this allows the AHRS subsystem to report its health. It would report
as unhealthy if (for example) EKF diverged and DCM tookover while it
recovered
MAVUtil: Recognize Tri, Hexa, Octa and Tradheli as using the ACM Mode Map

Without this change, MAVProxy et al doesn't work for copter frame types
other than quad.  This manifests as an inability to change modes and an
exception whenever one types an unrecognized command (as MAVProxy tries
to map them to mode commands by default)

To have true coverage of the ACM codebase, MAV_TYPE_ROCKET would need to
be added to the list also as ACM uses this for FRAME_SINGLE (MAVLink not
providing an actual Single class). I don't want to be the one to extend
that hackery in to generic MAVLink code though!

Types that are copters but aren't implemented by ArduCopter (e.g.
COAXIAL) are similarly left out of this PR.
pymavlink: fixed SERIAL_CONTROL support for new python array semantics
pymavlink: workaround a kernel baudrate set bug

sometimes some Linux kernels don't set the baudrate correctly
pymavlink: closer to supporting python3