QSPI overhaul and QSPI ClockV2

[rnd-ash]

Summary

As part of #912 , this PR overhauls the QSPI module (Only used for ThumbV7 targets) to use the ClockV2 API. In doing so, I have also overhauled the module such that it no longer goes on assumptions like it did before.

New features

• QSPI builder - Set target SPI speed and SPI operation mode
• Use Clock V2 API (user has to pass EnabledGCLK0 to QSPI builder) - EnabledGclk0 is used as QSPI is tied 1:1 to CPU speed, which is tied to Gclk0.
• Add scramble support for QSPI
• Use AHB Token rather than mclk
• Added documentation to the QSPI module on how to use it, and document pitfalls that a user might encounter (Warning of the fact QSPI stalls the CPU so long operations like Erase can make the program freeze)
• Removed QSPI builder functions in the BSPs (Now redundant)
• Migrate pygame QSPI example to Clock::V2

Improvements

• Don't force SPI Mode 0
• Don't force 4Mhz SPI operation by default
• Don't assume the CPU is always running at 120Mhz

Marked as a draft at the moment as examples are broken.

[kyp44]

@rnd-ash I don't know much about the QSPI, but evidently it has two AHB clock buses, CLK_QSPI_AHB and CLK_QSPI2X_AHB, represented in the v2 API by clock::v2::types::Qspi and clock::v2::types::Qspi2x, respectively. Your PR here just requires the AhbClk<Qspi> . Do you know what the AhbClk<Qspi2x> is used for and whether it is needed based on the way the abstraction uses the QSPI?

[rnd-ash]

@kyp44 I had a talk with @bradleyharden about this in Matrix. It seems that 2x AHB clock is only used for DDR mode QSPI. So I added a comment to the QSPI peripheral saying for now DDR is not supported. As the AHB clock system will need to be rewritten to allow the QSPI module to enable/disable the 2x clock at will.

We never supported DDR in the first place with the QSPI module, so we are not loosing any functionality we had before with this PR.

[kyp44]

@rnd-ash Gotcha, it's fine to not offer DDR support at this point. I just wanted the rationale to be documented here.