X-Macros for keycode definitions.

[tzarc]

Description

Converts keycode generation to X-Macros. Useful for conversion to text-equivalents.

Types of Changes

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

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).

[tzarc]

Random selection of 100 boards show SHA1s match.

[fauxpark]

X() is already used by Unicodemap (for now)... and I feel like this is overcomplicating things a little.

[tzarc]

X() is already used by Unicodemap (for now)... and I feel like this is overcomplicating things a little.

For now, will change it to XX(...).

This is mainly for future work with scripting languages, inserting text-equivalent names into the scripting VM.
If there's no desire for it, I can close the PR.

Example:

// Register keycodes
const struct keycode_table_entry {
    const char *name;
    int         value;
} keycode_table[] = {
#define REGISTER_KEYCODE(name, value) {#name, name},
    FOREACH_QK_KEYCODE(REGISTER_KEYCODE)
#undef REGISTER_KEYCODE
        {NULL, 0}};

LUAMOD_API void register_globals(lua_State *L) {
    for (const struct keycode_table_entry *e = keycode_table; e->name != NULL; e++) {
        lua_pushinteger(L, e->value);
        lua_setglobal(L, e->name);
    }
}

[zvecr]

I share similar concerns, could we not just generate a different header from the cli? I guess that would be my preference. Would the test header not be close to whats required?

[fauxpark]

As of #21092 X() is now free to use.

There's also the sendstring keycodes which use an X_ prefix but it doesn't affect this PR as much, and I'm not sure what to do about those yet - things like X_LCTL -> SS_LCTL vs the existing SS_LCTL().

[tzarc]

No probs, will move further discussion to Discord.