Feature/Enhancement: Allow Default Keymaps per Layout Macro

[noroadsleft]

This restructures the default keymap system such that each layout macro on the keyboard can have a default keymap, independent of the other layouts that can be used by the hardware.

Pros

• potentially less headache to users who build their keyboard with a physical layout that doesn't match the default

Cons

• creates a lot more keymaps to keep track of (possibly mitigated in future by qmk_firmware moving to default keymaps in JSON rather than C)
• possibly more labor required from designers who submit their boards/keymaps to QMK

Things I'd Like to Have for This Feature...

... but probably don't know how to achieve yet:

• Layout drop-down menu sorted alphabetically in the UI
  • potentially with LAYOUT_all, LAYOUT and KEYMAP macros listed first, then the rest in alphabetical order
• Some way of tracking changes to default keymaps in qmk_firmware
  • I could maybe solve this locally and not have to do it through the API or something
• Keyboards with a Community Layout macro but no keyboard-specific keymap file fall back to using the samples in public/keymaps/_generic/
• Some way in the UI of conveying to the user which macros have/don't have a default (excluding the above)
• Disable the Load Default button if a keyboard doesn't have any default keymaps pre-loaded (excluding the two situations above)
• ???

Review / Discuss Please

• @yanfali
• @zekth

[yanfali]

While I admire the ambition I'm not thrilled with the implementation. I kind of wish you'd discussed this in an open forum rather than doing what is a remarkable amount of work. In general I don't think this is a scaleable or verifiable approach

What I would have preferred is one file per keyboard. Each file contains multiple entries. It would be no worse than what we have today but would allow us to automate verification using tooling.

Let's talk offline about some alternative approaches.