[Keyboard] Add Kyria rev3

[leah-splitkb]

Description

This pull request adds support for splitkb.com's latest product, the Kyria revision 3.

It is the third revision of the Kyria, bringing it in line with the recently released Aurora range. It is a complete redesign, necessitating a new revision.

The Kyria rev3 will become available for sale in the next few days at splitkb.com

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

Notes

• In line with the Aurora range. this PR also adds a debug keymap, which should make debugging hardware issues a bit easier.
• The Kyria rev3 uses data-driven configuration, which meant we had to make some minor changes to the root-level and rev1/2 configuration. Those changes should be a no-op.
• The Kyria rev3 has the RGB Matrix enabled by default. Previous revisions had RGB Underglow enabled by default. This, in addition with a now-added brightness limit, is causing some compile errors on existing keymaps. Those keymaps still compile fine with rev2. Are we expected to fix those?
• The via keymap fails to compile, primarily due to a custom LAYOUT macro which includes encoder actions. Although it would be strongly preferred to have a working via keymap I do not quite understands its functionality, so I did not feel comfortable modifying it. Could someone provide some assistance with this?

[splitkb]

Hi! I'm wondering, has anyone had the chance yet to look at this pull request?

[zvecr]

The PR makes changes to user keymaps, which the current process requires either:

1. users to sign off on the changes
2. PR goes via develop

As it was mentioned on Discord as something that might require a timely merge, you are going to want to solve the whole #include "kyria_layout_stack.h" thing without changing user files (as user sign-off is usually extremely slow or a complete blocker).

[leah-splitkb]

I updated the PR to undo the user keymap changes.
In order to ensure compatibility I added a LAYOUT_stacked definition to rev3 too, we'll probably create a PR to develop at some point in the future to get rid of it.

@fauxpark could you clarify your requested documentation changes? The files already exist like that for all our other keyboards, so I don't quite understand why the Kyria is different. Could you shine some light on this?

[fauxpark]

There's no need for license headers in rules.mk files, as they're more configuration than actual code. As for the readme changes, it's best to format those three lines as a list instead of relying on the invisible whitespace at the end to create a newline: https://github.com/qmk/qmk_firmware/blob/master/data/templates/keyboard/readme.md

[leah-splitkb]

As to the rules.mk license information:
There are currently already (at least) 63 Makefiles which include license information, including the entire Aurora range which got it merged without any comment on it. Neither the Coding Convention nor the PR Checklist say anything about it one way or another. Additionally, config.h files are also more configuration than code, and those almost universally include license information - and are in fact required to by the PR Checklist.

As to the readme changes:
While I am in no way opposed to it, the suggested changes touch stuff which has been like that in the repo since the Kyria was initially added in 2019. In mid-2021 it was copied verbatim by a core QMK contributor, see #13511. A quick search shows that there are (at least) 435 keyboards in the repo where that part of the readme are not list-formatted.

I don't mind the suggestions. I fully understand the desire to keep it consistent and well-formatted.
However, the required changes come out of the blue. They were never an issue in the past, and now they are important enough to not only require fixing, but are suddenly a blocker.

I don't understand where this is suddenly coming from. I am more than willing to adhere to any documented and well-enforced standard, but to be very blunt this just feels like busy-work to me. I have made the changes to get this moving again, but I can't say I am very happy about it.

[tzarc]

For rules.mk and license headers -- I've updated the PR Checklist with clarification. As @fauxpark mentioned there's no need, but at this stage we won't require addition nor deletion of a license header for assignment-only Makefiles. If there's logic, then it'll be required.

For readme.md -- this is likely a case of the reviewer remembering about those items. The PR checklist already said to use the template, which does not contain trailing whitespace -- as you can probably imagine, a very significant number of keyboards are blatant copy/paste, and reviewers sifting through each proposed change inevitably end up noticing and/or enforcing different items, especially when the requirements change over time -- we're all human. Coincidentally, this is why we require two approving reviews -- the hope is that we cover most, if not all, of the items.

The move to data-driven allows us to leverage tooling to perform a lot of the validations and not miss stuff, but readme's have not been on the list (so far).

[splitkb]

It seems as though the QMK CI build is failing a few keymaps that are also failing in the main branch, and I think all requested changes have been implemented. Looks like it's ready to go, unless I'm mistaken - please let me know if it requires anything else :)