trackball: Add automatic flashing command

See merge request reform/reform!52

reform2-lpc-fw: write out descriptive error if REFORM_MOTHERBOARD_REV is missing

See merge request reform/reform!53

Implement fade-in & fade-out animations for keyboard backlight

See merge request !51

Add a ~30s timeout to the MNT Reform logo on the OLED

See merge request reform/reform!50

trackpad-fw: Make trackpad more responsive

See merge request reform/reform!49

Same as for the trackpad, a new 'JTBL' command can kick the device into
bootloader mode, to make flashing much more ergonomic. No need to access
the programming switch and reset button, just run flash.sh

Document the new automatic bootloader mode, and some other details as
well.

A new 'xJTBL' command can be sent from the host, which causes the
trackpad to jump to the bootloader.
The flash.sh script now sends this command, waits for the trackpad for a
bit, then flashes the new firmware.
With this change, one no longer needs to disassemble the Reform to
access the mode switch and reset button on the back of the trackpad
unit.

This mode is entered by default after about ~30 seconds of no touches,
and this results in the mouse freezing for a bit on the next touch as
the sensor wakes back up.
According to the datasheet, the sensor typically consumes 2.8mA in
normal idle state, and typical 1uA in the LP1 power state, so we will be
consuming a bit more power.

Instead of skipping first 4 readings, which incurs a slight latency
penalty at the start of a touch event, we clear lastx/lasty values as
touch events end, and check them before computing deltas. This way, at
the start of every touch event, we only lose one potential delta, and
then start tracking right away after that.
It should be noted, that manual delta computation is only used for
multi-finger gesture tracking at the moment, as the Azoteq sensor
provides smooth relative delta values for us in the case that only one
finger is active.

Removing the averaging makes the cursor and scrolling motion feel much
more precise and responsive. There is no longer a 'latency' to it.

The Azoteq sensor gives us a nice delta we can use in the case that
sensor.num_fingers == 1.

No functional changes. Just cleaning up some of the copypasted stuff,
like the register definitions for the trackball sensor. Also made
indentation consistent (2 spaces)

No functional changes. Trackpad motion logic was left as is here, and I
just introduce the new azoteq structs + the function to populate them.
Readability of input processing code benefits greatly from this
structured approach, as there are no longer any magical data shuffling
from a raw byte buffer in there.
Downside is, that we have to swap bytes for 16-bit quantities in the
structs, but that's not too much overhead on a 16MHz MCU.

This should prevent any burn-in caused by the logo staying on the screen
for too long. That can happen e.g. during brownout in a low battery
	condition. When the keyboard receives 3.3v standby power again, it
	shows the logo, and never clears it until the user does so. This
	should fix that.

It now smoothly fades in the backlight on startup. If running in
standalone mode, it does it right when it receives power, and on the
Reform, when USB power gets enabled about ~20s into boot.

Fix jumpy keyboard backlight adjustment

See merge request !48

Here, I actually adjust the hardware parameters, these settings work the
best based on my understanding of Atmel docs, and experimentation.

The key change is to set the clock select parameters to choose a
prescale that divides the IO clock by 8.
In the original implementation, a comment implied that the intent was to
set the prescale to /256, but the actual code just sets the first CS00
bit of TCCR0B, which selects no prescaling.
Now, we explicitly choose a prescale of clock_io/8, which seems to
result in the desired behaviour. The brightness increases and decreases
in equal increments, with no jumps with dead keypresses in between.
There are now 1+8 brightness levels, that is, 'off' + 8 levels of
brightness.
Going any higher than a pwmval of 8 with these settings causes the
backlight to blink, I believe due to overcurrent protection.

This first commit just aims to make the keyboard backlight pwm setup
code a bit more obvious, it's now broken up into sections, but the
original behaviour is intact.
The only functional change is, that each bit is now explicitly set to
the intended value. It's my understanding that clearing a bit like
this:
value = (0 << offset);
does not work. Instead, bitwise AND must be used, along with NOT, like
so:
value &= ~(1 << offset);

It may be possible that this functional change affects behaviour, as
those bits are now explicitly set to the intended value, but the
behaviour observed is unchanged.

Enable USB HID commands to address all 128 display columns

See merge request reform/reform!47

This was clearing the display using the multiple of 6 font width
assumption of the firmware text drawing code, so it didn't clear the
rightmost 2 columns of pixels. Using the direct clear command resolves
this.

The 'xWBIT' now supports addressing the full width, so update the demo
to match it.

The ColumnAddr (0x21) command in matrix_render_direct() was erroneously
setting the column end address to 125 instead of 127, which made it
impossible to address the rightmost two columns of pixels on the display
from USB HID 'WBIT' commands.

The 126 pixel limit exists for text and graphics drawn by the keyboard
firmware to simplify text drawing, since the firmware font width is 6px
per character, and 126 / 6 == 21, a nice round number.
I see no reason to impose this limit on arbitrary bitmap content drawn
by commands from the operating system.

Create all the keyboard V3 layouts (SVG)

See merge request reform/reform!46