consider mechanism to lock essential GPIO pin functions

I discovered recently that ITM is (and has been) broken -- but only on one board (the Nucleo H743/H753). I definitely didn't take the shortest route to debug this problem, but -- with a tip of the chapeau to Robert Ledru -- it turned out to be due to my enhancement of the SPI driver as part of eee1bb8e4fba0b7ac2bfecd0d8b4c4709c5cc67d. That commit takes several pins for SPI on that board (PA4, PB3, PB4 and PB5). The problem, as it turns out, is that PB3 AF0 on the H743/H753 is TRACESWO -- changing the function on that pin turns off ITM. On the one hand, this is yet more evidence that ITM (and SWV/SWO) is considered fringe rather than essential: unlike SWDIO and SWCLK (each of which has their own dedicated pins that can't be used for anything else), TRACESWO is forced into the general GPIO population where this kind of programming mistake is possible. But it also may highlight a slightly more general issue in which we may want to lock pins to a purpose and not allow them to be programmed? (One could imagine the GPIO task getting configuration for pins that cannot be reprogrammed, similar to what we have done with I2C in the application TOML.) Clearly, this specific problem needs to be fixed by Not Doing That, but it would nice to not reintroduce this.

Start by reviewing commit eee1bb8e4fba0b7ac2bfecd0d8b4c4709c5cc67d and the SPI driver changes affecting PA4, PB3, PB4, and PB5 on the Nucleo H743/H753. Then inspect the GPIO task and the application TOML I2C configuration for existing pin restrictions. Done means a decided mechanism prevents essential functions such as PB3 TRACESWO from being reprogrammed without breaking intended GPIO configuration.