Remove invalid pin_compatible config from defaults

[zvecr]

Description

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

[sigprof]

What do you plan to do about Elite-C — update its defaults some time later in develop and fix the fallout there? Having "pin_compatible": "promicro" for Elite-C is wrong in general, but it is not possible to detect automatically that some keyboard has "development_board": "elite_c" only because its maintainer wants the default firmware to match the controller that is commonly sold together with the board. Or should those cases use "development_board": "promicro", "bootloader": "atmel-dfu" instead (which would require #19511 to work)?

(Also it's sad to see the loss of information like #18880 (comment) only because info.json is named as if it actually was JSON.)

The rest of this PR looks correct though.

[zvecr]

The long term plan is potentially that the elite_c converters can fulfil promicro targets too? Some form of inheritance on the imaginary interfaces they provide. Few issues stopping that at the moment that myself/someone will have to work through.

Short term, I guess i'm not a fan of "development_board": "elite_c" then being used with promicro converters. However as all it does is set bootloader, which the converters will then override, I cant see it doing too much harm if it doesnt use the extra pins.