Apparently this is what we have to do to end up with correctly split
flags being passed into micropython qstr machinery...

We're going with spirals for the production model, and the code fork
doesn't make much sense anyway, as it all ended up being the same (so
far). Whenever the behaviour between spiral/spikes changes, we should
just drop support for spikes.

This is the most common badge prototype version at this point.

We have newer badges available for everyone to develop against, and p1
is so different from everything else that it's really not worth
maintaining support for it anymore.

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...