DMA SPI support for STM32 devices

[multiplemonomials]

Summary of changes

This MR adds a feature that many have been requesting for years: the ability to run SPI transfers in the background via DMA on STM32 devices. I based it on a test implementation for STM32L4 by @ABOSTM (also credit @wdx04's BurstSPI library). Luckily, these branches include most of the actual DMA code needed to make SPI work. The hard part is that the ABOSTM code only works for one specific device family, STM32L4. There are also some major bugs with how the interrupts are set up, so I don't think it actually worked.

So, to adapt that code for other STM devices, I added a new "stm_dma_utils.c" layer which abstracts the SPI code from the processor-to-processor differences. I also moved configuration into a new "stm_dma_info.h" header which is different for each device family and contains the DMA channel mappings.

Now, with this code, you can enable DMA with SPI::setDMAUsage(), and the next SPI transfer after the DMA usage hint is set will allocate the needed DMA channels and structures.

Lastly, I added a new SPI::transfer_and_wait() function to match the I2C::transfer_and_wait() function added a while ago.

** Still TODOs:**

• Add stm_dma_info.h for most remaining processor targets
• Run more tests

Impact of changes

STM32 devices will now support DMA.

Migration actions required

None

Documentation

None

Pull request type

[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[X] Tests / results supplied as part of this PR

Currently I have tested this locally on STM32L452 and STM32H743ZI. Pending testing on other boards.

---

Reviewers

---

[multiplemonomials]

This is now soooooo close to being ready to merge. I have tested it on STM32F4, STM32L4, and STM32H7, and it works for basic transfers and to initialize an SD card!

There is just one significant issue, which is that on STM32H7, calling abort_transfer() causes every subsequent transfer to be corrupt. I shall look into that. Also I should prob test on STM32U5. But still, never been closer!

[JohnK1987]

Is it ready or still in ongoing?

[multiplemonomials]

ok @JohnK1987 I think I'm good to merge this as an initial attempt now. I just pushes a commit which fixes hang issues on STM32F2, F4, and F7. It's hard to tell if it's actually perfect or not (because my bus pirate is broken now) but I think it's mostly working on most devices and I don't want to squeeze any more changes into one MR. I will open tickets to investigate the abort_transfer() issue and also investigate issues on STM32U5!