Adaptive reporting

There are still a couple bugs to be worked out, but this is the basic implementation of an adaptive, self-descriptive reporting format.  It currently supports defining any of [ count, min, max, mean, sum ] to be calculated over:
* The entire duration of the report
* Each defined interval "bucket"

Importantly, each report contains all information necessary for the server to parse the report, with no requirement for stateful knowledge of the monitor's reporting configuration.

There is a new tool, `reportinator`, with commands `start` to start regular reporting, `stop` to stop it, `send` to push a single report, and `parse` to parse a base64-encoded report string.

As an example:
```
report_interval = kEveryMinute;
bulk_aggregates = kAggCount | kAggMin | kAggMax;
interval_aggregates = kAggCount | kAggMean;
```
And then running `momosensor emulate 11` (generating a random value every second) will generate the following report (in base64, it can be parsed to meaningful values as below with `reportinator parse`)
```
version: 2
sensor: 11
sequence: 1
flags: 0
battery charge: 3.69V
diag: 57, 0
Interval type: second
         step: 6
        count: 10
Global aggregates:
	count = 57
	min = 9
	max = 992
Interval Aggregates:
           count    mean
               4     610
               6     522
               6     636
               6     386
               6     215
               6     567
               6     618
               6     443
               6     301
               5     487
```

Values of note:
* sensor: the address of the sensor module from which these events originated.  Currently only one sensor is supported, other events are dropped
* sequence: how many reports have been generated since the controller powered on.  TODO: make this durable
* flags: (currently unused)
* diag: 2 16-bit diagnostic values, usage TBD.  Currently diag[0] is the event count before this report was generated, making it easy to determine if events were skipped or outside the time window
* interval: 10 6-second buckets

Next steps:
* Ideally the settings for tuning reports would be durably configurable, that's still TODO but shouldn't be hard.
* Support multiple sensors
* Currently all supported reporting intervals are primitive alarm intervals and will fit in 1 SMS with 2 values per bucket (plus 3 or more bulk aggregates).  Eventually this should support compound intervals and overflow SMS
* There's still a bug I'm trying to track down with generating reports over large sets of existing events, causing the controller to crash.
* There's some contention between report generation and sensor value pushing, this should be resolved if possible.