Substantially rewrite persistence module with new approach to what the
underlying data we need to store. The external interface doesn't change
much; the internals and schema changed a lot.

Now we just store the actual events that happen to devices, level at
time, and we also store extra events for 'startup' (meaning we don't
know what happened previously) and 'checkpoint' (meaning we do know
what happened previously). Time-in-state calculations are done on the
fly by walking the event list in time order, looking at pairs of states
as denoting the ends of an interval, and for appropriate event codes,
we know the state during that interval.

I threw out the bucketing/rollup area of the schema since it was never
implemented anyway, and it'll likely be different if I ever get around
to doing that.

The new implementation is easier to understand and reason about, and
actually stores and provides more information (especially, it can report
a list of all events for a given device, which is something I've come to
care about). The downside is it does more work at query time; it stores
all events forever (for now) so the database grows without bound, and it
has to walk the entire change history for a device for some queries. I
suspect this won't actually be a problem for some time, so hey, down with
premature optimization. Someday I'd like to add historical aggregates and
rollups, and if the data volume becomes a problem, that's probably the
way to handle this.
Fix buglet where Lutron dimmable lights and shades had level_step
of 100 instead of 1, so the UI showed a switch instead of a slider.

Using class variables this way may well be an abomination, but it
works if I'm consistent (and fails badly if I'm not).