midnights: very close, off by one

Only two bytes are needed to encode time.
Seems to go like this:

```python
>>> month_bits = "{:#010b} {:#010b}".format(0xE0, 0x00)
>>> month_bits
'0b11100000 0b00000000'
>>> day_bits = "{:#010b} {:#010b}".format(0x1F, 0x00)
>>> day_bits
'0b00011111 0b00000000'

[ 0b11100000, 0b00000000 ]

[ 0b00011111, 0b00000000 ]

>>> year_high_set = "{:#010b} {:#010b}".format(0x00, 0x8D)
'0b00000000 0b10001101'
>>> year_no_high = "{:#010b} {:#010b}".format(0x00, 0x0D)
'0b00000000 0b00001101'
[ 0b00000000, 0b10000000 ]

```

I noticed the days have an off by one issue that gets particularly
exposed when midnight turns the last day of March into the First day
of April.  It must be some kind of joke that the high bit somehow
fixes, but I haven't quite grasped how it works yet.

As we'll see this algorithm decodes most dates, even with the off by
one/April Fool's problem.
re-engrave with midnight's decoded much better

In particular, this is suspect:
```diff

     hex
tweak output of Model522ResultTotals

The date_length is only 2 bytes long... this engraving helps illustrate which
bytes to look at.
re-engrave with 2 byte dates
Also customize older midnight records

2 byte handling seems to work...
re-render with older midnight records redone
add list of midnights in one place
tweak size/shape of old midnight records
re-render with smaller date_length on older midnights