We ripped that out when initially porting VfsPosix to work on ESP32.
This re-introduces it.

Fixes #10.

We were keeping GCable pointers to JackPin inside static structures
without adding a GC root. That meant that the GC was free to collect
them and re-use memory for something else, leading to weird UAF bugs,
especially when soft resetting.

We could've added a GC root, but it's easier to just statically allocate
the JackPin objects, too.

This makes sure we don't start claiming to be a ttyACM device before the
user actually enables USB.

st3m_io_badge_link_set would squash previous state.

This change makes st3m aware of what Micropython is doing, and lets st3m
provide some 'failsafe' functionality even if Micropython crashes.

Most notably, this lets us draw some useful messages when the badge is
in REPL mode, and lets us implement things like restarting the badge via
buttons if that happens.

This API isn't fully used yet, but this is a start.

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.

This moves our console implementation over to a CDC-ACM based one,
instead of using UART/JTAG.

This allows us to run multiple USB modes, and have prettier USB device
strings :).

The downside is that you now have to boot the badge into bootrom serial
mode before being able to reflash, but I have An Idea On How To Fix This
(tm).

This implements a st3m-specific USB stack. It's effectively what
espressif provides with their esp_tinyusb component, but allows for
dynamic reconfiguration of the USB device.

This comes form the ESP component registry, but we just want to vendor
the code instead of relying on package management.

Plus, we need to hack CMakeLists.txt to make it work with our setup, for
some reason. Otherwise we don't get callbacks...

Hacking on things is fun, but accidentally doing machine.Pin(1337).on()
and frying your flow3r isn't. Especially if you're just copypasting code
from the Internet.

We might add some escape hatch for this later for board
experimentation/testing/debugging..?

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.

This is replaced by more mpy-centric code for user interaction plus
bl00mbox for the actual sound framework.