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.