arch/arm/stm32: Support optional TX/RX UART GPIOs.

[alexcekay]

Summary

The STM32 serial drivers already treat 0 as not present for optional GPIO fields (CTS, RTS), guarding each call site with a != 0 check.

TX and RX GPIO fields lacked this guard, so boards that define GPIO_UARTx_TX or GPIO_UARTx_RX as 0 (pin not routed) caused stm32_configgpio(0) to be called, which silently configures PA0 as a floating input, corrupting any other peripheral using that pin.

Having an optional TX/RX UART is useful for several cases:

• RX-only connections: e.g. radio control input on flight-controllers where no TX is wired.
• Single-wire (half-duplex) connections: e.g. ESC telemetry connections.
• Output-only NSH which prints output but does not allow entering inputs.

Without a sentinel value for these cases one must assign the unused GPIO to a NC pin, which is misleading when reading board configuration files.

This PR adds != 0 guards for tx_gpio and rx_gpio across all STM32 serial driver families.

Using 0 as the sentinel is safe for TX/RX because any valid UART config requires GPIO_ALT bits set in the config word, so 0 can never represent a real TX or RX pin configuration.

Impact

• For users that already define a GPIO_UARTx_TX / GPIO_UARTx_RX as 0 this fixes the problem of unintendedly altering PA0
• As 0 is not a valid TX/RX pin config for any UART GPIO this change does not break any existing behavior

Testing

Tested on a v6s flight-controller (STM32H743VIH6) where we have the following in the board configuration

#ifdef PX4_RESTRICTED_BUILD
# define GPIO_UART4_RX   0                                         /* PD0 */
#else
# define GPIO_UART4_RX   GPIO_UART4_RX_5                           /* PD0 */
#endif /* PX4_RESTRICTED_BUILD */
#define GPIO_UART4_TX   (GPIO_UART4_TX_5 | GPIO_SPEED_2MHz)        /* PD1 */

#define GPIO_UART5_RX   (GPIO_UART5_RX_3 | GPIO_SPEED_2MHz)        /* PD2 */
#define GPIO_UART5_TX    0    /* We did not route out the TX pin of UART5 */

With the change the following was observed:

• The NSH on UART4 correctly prints data in case PX4_RESTRICTED_BUILD is set but does not allow the user to enter data
  • So having a RX as 0 works as expected
• The RC input parser running on UART5 was able to read data correctly
  • So having a TX as 0 works as expected
• The problem of PA0 being set to 0 is not observed anymore