[Keyboard] Add Electronlab KLOR keyboard definitions

[Lefuneste83]

Electronlab KLOR keyboard definitions

-Electronlab built fork of KLOR keyboard definitions for use with RP2040 MCU boards

Description

This PR aims at bringing a complete set of features for the KLOR keyboard hardware, thus requiring the use of a RP2040 MCU due to space constraints on Atmega AVR chips.
Current version compiles without errors and enables all supported embedded hardware, as well as ability to chose any of the 4 layouts of the KLOR keyboard.

It is an initial PR and will likely require heavy scrutiny and revisions. I understand QMK aims at a minimal set of default features but the goal of this keyboard being to be feature rich, I have found many users struggling while trying to implement various functionalities. The goal of this PR is to bring a set of config files ready to be compiled with as clean as possible code following latest standard and syntax.

Types of Changes

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

Issues Fixed or Closed by This PR

Allows KLOR keyboard users to have access to a fully featured firmware which is currently impossible :

• 3 year old legacy files provided by the project creator will not compile against latest QMK codebase due to change in syntax and architecture
• Latest merged version under geistgeistgeist/klor will only bring a minimal set of hardware features as it is based on Atmega AVR definitions and firmware limitations

Checklist

• [ X] My code follows the code style of this project: C, Python
• [X ] 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.
• [ X] I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• [ X] I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[sigprof]

This is a preliminary review which points out the most obvious places that should be fixed. In particular, I did not actually look at the content of the default keymap, because it violates one of the items in the PR Checklist:

• default keymaps should be "pristine"

You may be able to add a "pristine" default keymap, and provide your fancy keymap as a “vendor” keymap. Also keep in mind that QMK Configurator currently generates a bare keymap that expands to just the keymaps array init and nothing else (and it would be a standalone keymap which does not inherit anything from default, so any code or configuration which is required for the keyboard to work must be at the keyboard level, not in the default keymap).

[Lefuneste83]

Thank you very much for the immensely helpful code review. This has helped me quite a lot progress in the migration to json definitions which still had some hidden secrets. Let me know of any further changes you deem necessary.

[Lefuneste83]

Totally cleaned up the default keymap.c for ultra minimal mapping and created a vendor specific keymap directory with extra settings enabled