Add support for RM2 with STM32F (429, 746)

[scaprile]

TO BE REBASED after merging #3083 (Ignore first 3 commits for review)

Introduces MG_TCPIP_EV_DRIVER, fired when the driver requests user action (see below)
Adds hs to enable "high-speed mode" instead of defaulting to keeping it enabled
Adds examples with actual SPI hardware, with and without FIFO

Rationale: CYW chips have this weird mode enabled by default. Instead of using SPI like the rest of the world and enabling this manually, these chips default to clocking data out with the rising clock edge (instead of the falling edge).
On a typical connection with long paths, this can actually be good, as there is a longer setup time for data arriving at the master. However, with short connections, there can be a race condition depending on master and slave logic thresholds (or master internal design), as both master data strobe and slave data change occur at the rising edge.
So, the driver initializes the chip according to the hs parameter and fires the aforementioned event, the user may just ignore it (ad hoc SPI with a PIO accounting for this) or catch it and change SPI settings (STM32F)
Response to TEST command on start, high-speed mode and 16-bit little endian (swapped words and bytes):

"FEEDBEAD" ("BEADFEED") is correctly decoded by the microcontroller, but the logic analyzer has a longer path and misses some bits.

Setup, change of speed, response to TEST command with normal mode and 32-bit big endian (all 32-bits from MSB to LSB):

"FEEDBEAD" ("ADBEEDFE"

[cpq]

MG_TCPIP_EV_DRIVER seems to do SPI setup in your particular case... Seems odd. The name of the event is vague, tells nothing about the purpose. The handler code just sets up SPI - well, shouldn't it be setup beforehand anyways? Just like we setup SPI for W5500 ?
It smells like MG_TCPIP_EV_DRIVER should not be there at all.

[scaprile]

MG_TCPIP_EV_DRIVER seems to do SPI setup in your particular case... Seems odd. The name of the event is vague, tells nothing about the purpose. The handler code just sets up SPI - well, shouldn't it be setup beforehand anyways? Just like we setup SPI for W5500 ? It smells like MG_TCPIP_EV_DRIVER should not be there at all.

@cpq. there's a looooong text with logic analyzer captures explaining the reason for this: PR description comment. SPI is actually setup twice.

wrt the name... well, I foresee different chips having different weird things requiring different actions, hence the name 'driver'; there will be driver-related events with driver-dependent meanings. In this case, there is no event data, in other drivers, there can be an event code telling the reason for the event and the handler can process that and react accordingly.
IMO, this is quite cleaner than having lots of callbacks around.