Somwhere in Micropython there's a `<io.TextIOWrapper 0>` from
vfs_posix_file that's getting garbage collected and which in turn
triggers the object's __del__ which then in turn attempt to close FD 0.

Let's not allow that to happen by adding some ugly hardcoded deny list
for FD 0,1,2 in the close function.

Ideally, we would figure out why that object exists, why it gets garbage
collect and what really should happen here. But this is good enough.

This moves the raw read/write access code from the recovery mode into
st3m, and gives us the ability to mount/unmount the FAT partition on
demand.

Only ctx.arc has a 6th integer argument, integer truncation was applied to
all 6-argument methods.

We attempt to share st3m with the recovery firmware, and thus must
eliminate two components that can't live in the recovery firmware:

1. The startup function, which contains references to all matters of
   subfunctionality we don't want (audio, micropython, etc)
2. The FS code, which contains references to the tarball extraction
   logic (which we don't want to embed into recovery mode either).

We don't pre-generate a FAT partition anymore.

rip 2023-2023

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

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

Fixes #10.

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.

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

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

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.