We seem to be wasting a lot of internal memory on random mallocs(),
preventing us from late-initializing bluetooth/BLE.

Fixes #13 . Maybe. We'll see with time.

I think a more complete approach would be to force all micropython
allocations to land in SPIRAM? Or maybe use some memory watermarking to
make the micropython allocator only use internal memory if there's
plenty of it available, enough to initialize BLE?

As we don't use the UART/JTAG detection mechanism anymore for rebooting
into bootrom serial, we can use the stub again, which makes things much
faster.

We don't care for it much in our usecase, and it reduces performance.

At least I think so. We might want to roll this back later :).

This doesn't seem to be less performant than the rube goldberg we had
previously, but somehow fixes up rendering glitches.

Phew.

This was mostly blocked by Micropython, but it has since then also
upgraded to IDF 5: https://github.com/micropython/micropython/commit/e4650125b88a35f074097f16d84a8f49bd22ac06

We take that change and selectively apply it where necessary. However,
it's not a 1:1 patch apply, as we already were on a somewhat forked
Micropython, and we also want to support IDF 5.1, not 5.0.

We also bump up the IDF distribution brought in by Nix, and fix some
warnings that have since turned into errors due to toolchain changes.

Removes sdkconfig.p* files, use a single sdkconfig.defaults.

This is now 'overlaid' with flow3r-specific options by idf_ext.py.

The stub seems to break uploading from running firmware on newer
ESP-IDFs.

There's a better way to fix this by patching esptool.py, but this is
good enough for now.

https://www.esp32.com/viewtopic.php?t=10184#p42176

This replaces the original GC9A01 driver with one optimized for our
usecase, implemented directly in a brand-new BSP (board support package)
component.

The major differences between the drivers are:

 1. aware of different badge generations
 2. generic: still supporting the possibility that we might have to
    switch to a different SPI display at some point
 3. only supports writing entire screen at once from in-memory buffer:
    no line drawing, filling, etc.
 4. spi screen blitting does not waste CPU time, instead uses
    ESP-IDF/FreeRTOS DMA/Interrupt logic to perform transfers
    efficiently.

We also drive-by enable SPIRAM, as we're starting to run out of memory.

This moves badge hardware generation selection over from a header file
into ESP-IDF configuratbility.

The generaiton can now be selected by specifying `BADGE_GENERATION` or
`-g` when running the initial built.

In addition, each generation now gets its own sdkconfig.defaults file
(instead named sdkconfig.$generation) and the big autogeneration
sdkconfig file gets yeeted.