Sensor abstraction

@zelch made a comment in #16 that got me thinking about sensors and widgets, and where we might take them to make adding support for more widgets and more devices easier.

There are a finite (and small finite) number of sensor types. Most are measurements, but some have a time series component. One is a list (procs). There are a similar finite number of widget types: histograms, bars, and lists. The current design abstracts (most) devices away from widgets, and it could be further abstracted so that devices themselves aren't so coupled to a specific widget type.

Device registration interface might look like:

func register(sensorType string, dataType interface{}, callback func(data map[string]interface{}) map[string]error) {
        // ...
}

with the CPU devices self-registering with:

func init() {
        register("FAN", true, updateIntelFanData)
}
func updateIntelFanData(sensorData map[string]interface{}) map[string]error {
        // ...
}

and a configuration type defining widgets would be:

cpu=histogram,float,CPU
fanHist=histogram,bool,FAN
fanState=onoff,bool,FAN

such that a device registering itself with a specific (name, data type) tuple would be associated with a widget definition of matching tuple. Users could use the current layout configuration to define their interfaces:

cpu/3 fanState/1

which would render

+------------------------------+----------+
|                              |          |
|          CPU                 |    FAN   |
|                              |          |
+------------------------------+----------+

Most of this would be pre-defined, but it'd make adding new devices and widgets a matter of (either in plugin on in core code):

1. Add a device that has at least two functions (this is the current implementation):
   1. init(), in which it self-registers
   2. GEN_DATA_FUNC(), which generates data
2. Add new widget definitions for showing the data, using one of the existing base types
3. Add a sample layout using the widget

It'd require abstracting out the widget types. Also, some of those break down; procs can't be abstracted without getting into crazy land. I'd also be concerned about the performance to adding too much abstraction. Still, it might be worth investigating.

Some conversation on this topic was held in issue #79.