[WIP] Refactor CTPC logic to allow future converters

[zvecr]

Description

Initial steps at supporting additional converters.

Overall goals

• Introduce consistent convention to be followed
• Avoid pin_defs.h from becoming a dumping ground
  • Split out into their own files
• Validate converter can be applied to a given board
  • Something along the lines of adding PIN_COMPATIBLE = promicro and rules to only allow CTPC when compatible
  • This will block invalid conversion attempts, such as make xd48pro CTPC=yes
• Introduction of "promicro" "elite c" "blackpill" presets?
  • would set mcu, bootloader, and conversion compatibility
• Refactor existing boards to use presets or manually define PIN_COMPATIBLE - Remove converter assumption that everything is a promicro #20330
• Consistent handling of hardware config
  • currently fragmented between common_features.mk and convert_to_proton_c.mk
• Consistent handling of config.h/rules.mk config defaulting
  • rgb/i2c config for dma/pwm/etc
• Config of additional hardware
  • CTPC audio
  • bonsai flash/fram
• allow more shorthand along the lines of CTPC = yes?
  • current view is to remove shorthand
• keymap.json specify converter
• Tighter control of interface?
  • Intermediate stage could map arduino pin names?
• data driven?
• definition of optional pins ?
  • allow converted target to configure additional features without using low level gpio defines
• alias system to allow reuse of converter for compatible designs - Add alias support for converters #19563
• qmk info -f json -kb <keyboard> -km <keymap_with_convert_to> shows pre-converted info (incorrect mcu/bootloader/protocol/etc)

Notes

• Include path is not consistent enough to have the same header name for converted pin defs
  • Fixed up enough that VPATH modified early in the build process is enough
• How to infer the conversion makefile if located platforms/chibios/boards/QMK_PROTON_C?
  • Solved with relocation and glob
• platform board files inheriting from other platform board files?

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