- Remove the concept of "mcus". With only one target platform
(CircuitPython), it no longer makes a bunch of sense and has been kept
around for "what if" reasons, complicating our import chains and eating
up RAM for pointless subclasses. If you're a `board`, you derive from
`KeyboardConfig`. If you're a handwire, the user will derive from
`KeyboardConfig`. The end. As part of this, `kmk.hid` was refactored
heavily to emphasize that CircuitPython is our only supported HID stack,
with stubs for future HID implementations (`USB_HID` becomes
`AbstractHID`, probably only usable for testing purposes,
`CircuitPython_USB_HID` becomes `USBHID`, and `BLEHID` is added with an
immediate `NotImplementedError` on instantiation)
- `KeyboardConfig` can now take a HID type at runtime. The NRF52840
boards will happily run in either configuration once CircuitPython
support is in place, and a completely separate `mcu` subclass for each
mode made no sense. This also potentially allows runtime *swaps* of HID
driver down the line, but no code has been added to this effect. The
default, and only functional value, for this is `HIDModes.USB`
- Most consts have been moved to more logical homes - often, the main
or, often only, component that uses them. `DiodeOrientation` moved to
`kmk.matrix`, and anything HID-related moved to `kmk.hid`
The thumb cluster maps a little goofy and I'd like to clean up the
keymap here - it's ENTIRELY NOT OBVIOUS how this works right now. Using
this keymap as an example, the physical layout of my thumb cluster is
actually:
Far left: Left
Next to the right: Right
Bottom right: Shift
Top right: MO(2)
You can see what this maps to in code, and it's not at all intuitive.
`swap_indicies`, which we already support, is useless here because,
unlike the Planck/Klaranck, these aren't 1:1 key swaps, but an entirely
custom mapping of columns. This will require something like QMK's
solution to fully custom (or at least partially custom) keymaps at a
core level, and isn't something I feel like tackling tonight
necessarily.
