Convert keymap from list of lists, to flat list.

[kdb424]

This is needed for "non square" pcb's or ones that don't align the colums due to pin limitation. For example, the luddite is a "square" in software, each row is 8 columns, but that makes the keymap a lot harder to read. We should consider making this change during boot and forming the rows and columns for internal used based on pins, and not a user defined list of lists.

Example of why this is not good. https://github.com/KMKfw/kmk_firmware/blob/d5272ced192018137246ebe700640d87afe0638c/user_keymaps/kdb424/luddite.py#L49-L59

[klardotsh]

To add more fuel to the fire: another decent example of this grossness is to compare the following two Iris layouts (which, mind you, actually does lay itself out as a grid matrix, just a hacky and unintuitive one).

QMK: https://github.com/klardotsh/qmk_firmware/blob/6fe3b5c58ac5a66bf96ec3615d9cc9b55fd90f1f/keyboards/iris/keymaps/josh/keymap.c#L9-L16

KMK: https://github.com/KMKfw/kmk_firmware/blob/bcdc97a56bdd5fcd466fd6ad8e76f8598c8448c4/user_keymaps/klardotsh/kitsym4_iris.py#L75-L81

Notice how screwy the bottom row became. It took some serious trial and error to actually figure out where those keys were supposed to live, and swap_indicies more or less can't work with this in any reasonable way (believe me, I tried).

[kdb424]

QMK handles this with an external "mapping file" which I was not really a fan of, but it may be a needed evil as pin limitations are rough. In doesn't help that the maximum amount of keys is maxed out with a square. 8x8 = 64, 6x10 = 60 with the same amount of total pins. If we want to increase the size of supported boards, this is a consideration we will have to make sooner rather than later.

[klardotsh]

I've seen a few examples (I think the Iris is one) in QMK where the layout is defined within the *.c files for that keyboard, and the keys are basically defined as (hacky example in pseudo-Python)

[
    [K1, K2, K3],
    [K5, K4, K7],
    [K6, K8, K9],
]

where the user then defines (whitespace insensitive as always with QMK's macros)

KC_A, KC_B, KC_C, KC_D, KC_E, KC_F, KC_G, KC_H, KC_I

and gets a layout, thus, like this

A B C
E D G
F H I

I'd be fine with emulating something like that on our end: it'd eliminate the hack I made for the Planck r6 (swap_indicies), and would make the Luddite, Iris, and likely many other non-perfect-ortholinear-grid boards, a whole lot more intuitive on the user's side.

[klardotsh]

Let's prioritize this for v1 - regardless of which implementation, or who writes it, I think the irritation (and worse, unintuitiveness) is impactful enough to warrant a pretty high priority for a fix.