feat: add NVS pin profile override

[r3mko]

Problem

After the device pin abstraction in #1916, custom boards could be left with empty pin mappings, causing I2C and BAP initialization to be skipped. Custom boards also had no way to select the newer Bitaxe Color pin layout.

Solution

• Add BITAXE_ORIGINAL_PINS as the fallback for custom boards without an explicit pin configuration.
• Add an optional NVS pinprofile setting supporting original and color.
• Apply existing Kconfig BAP and I2C overrides afterward.
• Validate the final pin configuration as before.

Result

Existing custom boards remain compatible by using the Original pin layout automatically, while new custom boards can explicitly select the Color layout through config-custom.cvs.
If pinprofile is absent, recognized boards retain their compiled pin mapping and custom boards use the Original fallback.

Note

This selects between the two existing validated pin profiles. Arbitrary per-GPIO configuration remains out of scope.

[github-actions]

Test Results

  2 files  ±0    2 suites  ±0   1s ⏱️ ±0s
126 tests ±0  126 ✅ ±0  0 💤 ±0  0 ❌ ±0 
128 runs  ±0  128 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit a9d2162. ± Comparison against base commit 3a09ea0.

[mutatrum]

Custom boards can only function as a sibling of existing board family. You can pick any unregistered board number and pick the family for the pin config. If you have a custom board that has a different pin layout you have to build your own firmware, either by changing the code or setting KConfig values.

If we want to go towards full pin customisation, it would make more sense to have actual pin config values, but at the moment there is no request for doing this.

[r3mko]

Thanks, that clarifies the intended workflow. From reading the current code, a registered boardversion loads the complete DeviceConfig, including its pins, before applying supported NVS overrides.
However, an unregistered boardversion selects only a FamilyConfig, which does not contain pins; with the default Kconfig values of -1, those pins remain unset.

The fix (f29204f) initializes unregistered custom boards with BITAXE_ORIGINAL_PINS, while still allowing Kconfig overrides afterward. Is that fallback still considered valuable, or should custom boards always use a registered sibling board number