feat(shields): Enable wired split for ergodash, prep for other wired split in-tree keyboards

[nmunnich]

Currently, we disable the UART devices attached to pins of our in-tree boards. This is because when a UART device is enabled, the UART device will capture the pins it is assigned to, rendering them unusable for other purposes such as keymap scanning. UART is enabled by both ZMK Studio and USB logging, so we do not wish to have this enabled by default.

This PR demonstrates one approach for us to enable these UART devices for usage with shields that allow for wired split: We enable the correct UART device in the shield, alongside selecting it for usage with wired split. We assume that a shield which allows UART wired interconnect will not also simultaneously attempt to use said pins for some alternative purpose. If an add-on such as the nice!view with its adapter and bodge do wish to use said pins for an alternative purpose, then we see it as the add-on shield's responsibility to ensure that the UART device is disabled.

Ergodash is the in-tree keyboard used as an example, and credits to #3037 for beginning the topic.

[petejohanson]

A few thoughts:

• I realized we need to be careful of the power implications here. The runtime split work specifically does some device PM work to ensure the UART when unused is in standby. If we don't have that here, we may be increasing our draw non-trivially. This would need specific evaluation.
• I don't see an actual solution for the nice!view bodge scenario presented here. Just a note that would be their responsibility... What does that practically look like for end users?

[nmunnich]

• Would this need extra testing, or a code review, or what does this look like?
• For n!v, we have keyboards designed for use with n!v, and we have keyboards designed for use with an oled.
  • Keyboards designed for use with n!v will probably not be wired-split capable, and won't enable the node. Keyboards which are designed for use with n!v and are wired-split capable will very unlikely be sharing the pins for the UART and the n!v, and if they are for some reason, then that is their shield's role to configure (obviously, no in-tree shield applies to that configuration).
  • Keyboards designed for use with an OLED bodge the CS pin, and then need to use the n!v adapter, which disables the UART once more. Hence, users wouldn't need to do anything in particular.

The cases where a user would need to do something is if they've modified the n!v adapter to point to a different pin, in which case they would also need to modify their version to disable the UART. If you see another scenario we need to account for, I'm not seeing it.

The open question that I have is more along the lines of what this looks like once we have half-duplex wired split. I think most half-duplex shields already snag one of the UART pins for RGB though, and I don't have a clear picture of what half-duplex pinctrl looks like.

EDIT: I suppose there is also the case where a n!n or similar user may wish to bodge to the UART pins because they fried some other pins. That would be a weird bodge though, and we can make a note in hardware troubleshooting to account for that.