Rework of QVEX Lynepad implementation

[seflm]

Description

Rework of QVEX Lynepad implementation:

• Full VIA support (including encoders, and 4-way switch)
• Proper support of off-matrix 4-way switch using "virtual" rows
• Use RGB ring as layer indicator
• Retaining the original keymap of @mcrosson

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

#20493

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

[seflm]

Can we get this merged into develop before the May develop->master merge? Thank you

[lesshonor]

Can we get this merged into develop before the May develop->master merge?

Probably not.

[lesshonor]

Per the PR checklist:

• info.json
  • With the move to data driven keyboard configuration, we encourage contributors to utilise as many features as possible of the info.json schema.

The docs do have a lot of information on how to do it the old way—not everyone is running a recent version of QMK, for one thing. But new submissions will need to adhere to newer guidelines.

[seflm]

Thank you @lesshonor for the thorough suggestions.

I would like to make QMK a default firmware for the QVEX Lynepad. Is there a way to get it merged into master before the end of Q3 ? I suppose the maintainers could make an exception on the cut-off date of the develop branch as the reason for this getting merged into develop is just to reduce master -> develop merge conflicts. Or we could merge this into master directly as another qvex keyboard (something like lynepad_via) to comply with the PR?

keyboard updates and refactors (eg. to data driven) must go through develop to reduce master -> develop merge conflicts

[lesshonor]

I don't know enough about custom matrix wiring to provide any worthwhile analysis there. Seems fine to me. Good luck.

[lesshonor]

A collaborator may ask you to rehost this on a dedicated image-hosting service, but since long-time suggestion imgur is circling the drain I'm going to defer that to them. Just wanted to warn you.

[lesshonor]

Suggested change

	*Macropad with 11 keys, thumbwheel, and a rotary 4-way switch*
	Macropad with 11 keys, thumbwheel, and a rotary 4-way switch

No need for the italics -- they're only in the template to try and bring attention to a line that should be replaced (...submissions often overlook the readme)

[zvecr]

Closing as bot would have closed this ages ago, has conflicts, and would require a fair amount of changes to meet the current PR checklist.