Redesign EEPROM Keymap storage to be more extensible and flexible

[obra]

[this first somewhat sketchy description is extracted from notes on @hupfdule's PR #1340 ]

We need is some way to represent the data for what a key in the keymap does on long press in EEPROM, coupled with a way to mark a key on a given layer as having long-press behavior that needs to be resolved by the longpress plugin.

Right now, eeprom keymaps are 16 bits per key per layer (

Kaleidoscope/plugins/Kaleidoscope-EEPROM-Keymap/src/kaleidoscope/plugin/EEPROM-Keymap.cpp

Line 89 in fd7f5f9

void EEPROMKeymap::updateKey(uint16_t base_pos, Key key) {

) - 8 bits for the primary keycode and 8 bits for flags describing modifications to that keycode:

Kaleidoscope/src/kaleidoscope/key_defs.h

Line 39 in fd7f5f9

// Constant flags values

Plugins can define ranges of keycodes they use for their own specialized behavior, but those ranges are somewhat limited. https://github.com/keyboardio/Kaleidoscope/blob/master/plugins/Kaleidoscope-Ranges/src/Kaleidoscope-Ranges.h#L83

So we could set up, say, 32 "longpress" keys that get handed off to the longpress plugin for evaluation, sort of like how we do Dynamic Macros: https://github.com/keyboardio/Kaleidoscope/blob/master/plugins/Kaleidoscope-DynamicMacros/src/kaleidoscope/plugin/DynamicMacros.cpp

But that's not a great user experience and feels very...limiting.

It feels sort of like it might be time to think about redesigning how we store keymaps in EEPROM to make them more extensible. But that's not a small undertaking.

I'd dearly love to be able to support full configuration of LongPress, QuKeys, Chords, and all the rest in Chrysalis.