Initial DD keycode migration

[zvecr]

Description

Initial pass covers:

• basic keycodes
• keycodes expecting no arguments and have constant values
• ranges
  • including moving "variable" keycode values to static blocks (eg sequencer)

Due to the tight coupling in the code base, currently it has been chosen to not simultaneously support the current keycode values as a "legacy" version.

TODO

• "approve" new keycode ranges
• improve data folder structure?
  • data/constants/keycodes/ folder?
  • data/constants/keycodes/0.0.1/ folder for each version?
    • easier to merge without, more like xap
• fix issues
  • via will compile but not work due to range changes

Future

• sub ranges?
  • nest range objects?
  • specify as additional ranges?
  • specify values as fake keycodes?
  • validation of overlapping?
• Migrate anything keycode(with_args)
• keymap extras
• automatically regenerate files
  • static data so no point generating it 2500 times for each keyboard
  • pre/post merge?
  • actions?
  • reuse process for other features

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[zvecr]

Current Allocations:

area	number
quantum loose	512
keyboard	256
keymap	256

SAFE_RANGE currently maps to both keyboard+keymap - keyboard refactoring can happen at a later date

QK_MACRO block 128 keycodes (with room to expand to 256) potentially for https://get.vial.today/manual/macros.html#3-changing-the-amount-of-macros

[zvecr]

@fauxpark could you have a look at the allocated ranges and flag any potential issues or recommendations please.

[ToyKeeper]

This looks fantastic; huge improvement over the old disorganized keycode enums. While the keycodes are changing though, might it be worth taking the opportunity to sort a few? Like, the magic swap/unswap/toggle keycodes for each option could be grouped together.

[wilba]

VIA has been updated to use these new int values, still to do is the refactoring to the changed keycode names and adding new keycodes to the UI.