V2: Move all data gatherers into a plugin system.

V2 architecture:
- `overwatch.py` main loop only services hardware and the data dictionary, it does handle any senses or work with sensed data directly.
- performs startup, config, log setup, schedule init and running, signal handling and all other 'housekeeping' tasks
- provides gpio, I2C (and SPI) bus objects for the gatherers to use.
- directly handles all the button pin functions
- spawns rrdb, http, display and alert tasks/processes that drive the core functionality
- provides the global `data{}` dictionary
- uses queues for display and alerts by extending the dictionary methods for `data{}`
- gatherers focus on a single dataset, currently: 'system', 'environment', 'connectivity', 'pin'
- init
- updater
- handler for http (show_panel)
- Attributes (optional) for rrdb (limits, formats, graph)
- Attributes (optional) for display
- log directly
- alerters
- TBD: a plugin system for alerting
- run in a separate process, possibly demonised so it can alert if the main process dies..
- Pass the `data{}` dict to it via a Queue, same as for the display sub-process
- Allow it to pass data back to the Web interface and display can show alerts?

In General:
- We currently have tables defined in the http, rrd and display classes that should be moved out and become attributes provided by the relevant data gatherers.
- the http server needs to become 'data neutral' as well, gatherers need to provide their own generators (emitting a formatted http table header and rows) so that the `httpserver.py` module can become data neutral.