Add features to bootloader

[dkonigsberg]

This is a follow-on task for #9, and mostly a tracker for wishlist features.

The initial bootloader is fairly basic, and mostly focuses just on the success path of getting a firmware image from a USB stick into flash. It means the minimum requirements, but is far from ideal. Before it can be deemed "complete and ready for primetime" there are some features that should probably be added:

• Implement key event handling for u8g2 to enable actual menus and button-prompt messages.
• Provide Okay/Cancel/Yes/No type prompts at various stages of the firmware install process
• Implement an actual file-list capability from reading the USB stick, such that the firmware need not always match a magic name. This will enable giving firmware images a version-based name and allowing the user to select between different images on the same stick.
• Consider adding some sort of metadata block to firmware images, so that the bootloader can display/verify more detailed information than a simple size and checksum. This may also help prevent loading of arbitrary data or data meant for a different target device.
• Consider a bootloader menu with some extra features, and possibly even a reserved page of EEPROM for persisted bootloader settings (e.g. enable/disable checksum, enable/disable firmware features that should be completely hidden from the firmware when not enabled by the bootloader).
• Add ability to erase the settings EEPROM to a factory default state

The bootloader is the one component of the system that is essentially fixed in stone once the Printalyzer goes to a normal end-user, so making it "complete" prior to launch is a requirement. If that can't be done, then at least the firmware image format needs to be fixed in stone.

[dkonigsberg]

The bootloader should check if the selected image on the USB stick matches the already-loaded firmware, and prevent (or warn) if the user tries to reinstall. This will make things easier before actual image versioning/selection is fully implemented. Checksum verification can be used to make sure re-flashing corrupted firmware is still possible.

[dkonigsberg]

Several minor tweaks to the bootloader code: c20b7cc42736e02bdf5625c1c28896fdbd51f638 e451859c358f035950c923cc7c6ceae497c6218f 410bb24e9bcb13e39764709400dca801c6583abb 3d0756bd93f90e156e111c5c2fecc2ecf4b875d1 4a322cf6c6cfb84aff7d78472d3623cb75d40f19 c775bd0f646d28b603fc18bf85448c641befd60f

[dkonigsberg]

As work on the bootloader not all commits are being captured on this task. However, the scope of the bootloader has since changed. Originally the bootloader was given 128KB of flash, and had ample space for all of these extra features. However, this is way too much given that we only have 512KB of total flash and would rather reserve as much as possible for the actual firmware. Furthermore, adding too many bootloader features creates more opportunity for bootloader bugs, which will be almost impossible to fix once devices are shipped.

The new plan is as follows:

• Reduce the size allocated to the bootloader down to 64KB
• Strip out any unnecessary logging and peripheral initialization to help it fit
• Replace all text UI elements with simple graphics, which removes the need for fonts, text processing code, and potential localization concerns
• Add a mechanism for the main firmware to send parameters to the bootloader, letting the main firmware contain all the fancy menus for picking firmware update images.
• Keep the built-in update mechanism that always installs from a known-name file as a fallback for recovery purposes

In other words, the bootloader can still be dumb, as long as the main firmware has a menu where a user can browse a USB thumbdrive and select an image to install.