Update Keychron boards - Part 1 (redo)

[adophoxia]

Description

(This is a re-attempt of #21129 due to a merging mishap that I caused. Note to self: Never sync with master from github.com for a PR based in develop.)

Edit: Move #define DYNAMIC_KEYMAP_LAYER_COUNT to info.json

(Original text)

This is Part 1 of a 5-part series of PRs to updating the entire Keychron lineup to current QMK standards. Since doing 1 PR to update 25 keyboards is unmanageable, doing them in batches would help make it tolerable. This

Changes:

• Full DD-configuration wherever necessary (including RGB_Matrix DD-configuration)
• Moving common code to "keyboard" level files (Ex: q2/info.json/q2/config.h)
  • Encoder-specifc code like #define ENCODER_DEFAULT_POS 0x3 to the keyboard-level config.h inside of a #ifdef ENCODER_ENABLE block
  • rules.mk features into the keyboard level info.json
  • RGB Matrix effects and rgb_matrix driver (CKLED2001/IS31FL3733(Q1v1))
  • bootloader and MCU processor, diode_direction
  • This:

    "keyboard_name": "Keychron Q/V[XX]",
    "manufacturer": "Keychron",
    "url": "https://github.com/Keychron",
    "maintainer": "lalalademaxiya1",
    "usb": {
        "vid": "0x3434"
    }

• Updating readme.mds to include variants of boards forcompile and flash instructions and to provide imgur links

Keyboard-specific

• Q1
  • Update files to show as Q1v1 since there are two variants of the Q1, Q1v2 being the newer variant, and to partially restructure for when the Q1v2 gets merged into upstream QMK
  • Add Keychron Q1 Version 2 #20416
• Q4
  • Consolidate both keymaps folders from q4/ansi_v1 and q4/ansi_v2 to be under q4/ansi/keymaps instead of these 2 variants having their own keymaps folders.
    Basically going from this

     q4/
     ├─ iso/
     ├─ ansi_v1/
     │  ├─ keymaps/
     ├─ ansi_v2/
     │  ├─ keymaps/
  

  to this

  q4/
  ├─ iso/
  │  ├─ keymaps/
  ├─ ansi/
  │  ├─ v1/
  │  ├─ v2/
  │  ├─ keymaps/
  

Part 1 involves updating the following KC boards:

• Q0
• Q1v1
• Q2
• Q3
• Q4

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

[adophoxia]

Since July 30th is coming up as that's the date for develop being closed for new PRs, hoping this one and subsequent others are taken a look at.

[lesshonor]

Since doing 1 PR to update 25 keyboards is unmanageable, doing them in batches would help make it tolerable

...IMO, this is still too big of a batch.