rp2: No support for external pins in Pico W build
The named pins feature for supporting external pins requires the definition of machine_pin_ext_init and various other functions for configuring, setting and getting external pins.
This feature is entirely monopolized by the Pico W build, in such a way that it's impossible to add additional external pins on top of those defined for Pico W.
There should be no reason why we can't take a copy of machine_pin_cyw43.c , and extend it as necessary.
This would require moving the hard-coded exception for Pico W in CMakeLists.txt into the board config -
https://github.com/micropython/micropython/blob/3637252b7bc3e85ea92038161e008a550991d1f4/ports/rp2/CMakeLists.txt#L300-L302
ESP32 handles additional sources with the MICROPY_SOURCE_BOARD variable, I think the RP2 port should mirror this behavior, and this is how machine_pin_cyw43.c should be included - https://github.com/micropython/micropython/blob/3637252b7bc3e85ea92038161e008a550991d1f4/ports/esp32/esp32_common.cmake#L105
ports/rp2: Make pins.csv configurable.
Allow mpconfigboard.cmake to specify a custom MICROPY_BOARD_PINS to override ${MICROPY_BOARD_DIR}/pins.csv.
Summary
RP2350 has a "B" variant chip which could conceivably be configured in a board variant (big and small versions) and require its own, separate pins.csv config with the additional pins configured.
This may apply also to W and non-W versions where the CYW43 might need WL_GPIOn pins specified but there are otherwise few meaningful changes to justify entirely separate boards.
Finally the RM2 module support added by #16057 might need optional WL_GPIOn pins configured for traditionally non-W boards with added support for an external wireless module, though this is contentious since those pins wont be available without an attached module.
This PR is mostly to address point 3, in an effort to make the changeset in #16057 smaller and easier to review.
But it's also counter-intuitive to have support for variants without support for specifying variant versions of config files.
Testing
TODO! This would need a rebase of #16057 assuming this is even the way we want to approach the problem.
Trade-offs and Alternatives
I don't think there are any real downsides to this feature, though it should probably be reflected across all CMake-based ports.