Add support for optional SD Card programming

[Arksine]

This PR adds support for SD Card firmware programming in addition to the primary programming interface (ie: CANBus, USB, UART). Currently Katapult can be configured to use Hardware SPI and Software SPI for all supported MCUs. SDIO is supported exclusively for STM32F4 series MCUs. I recognize that there are printer boards that ship with STM32F1 and SMT32H7 series MCUs connected via SDIO, and will consider adding future support for those variants.

The primary motivation behind adding support is two fold. First, it provides a way to program the MCU when the primary interface is not available or not working. Second, many users have expressed a desire to switch to Katapult, however they do not want to lose SD Card programming offered by stock bootloaders.

The readme details how SD Card programming works, but I do want to note the major difference between Katapult and "stock" bootloaders. Katapult does not initialize the SD Card and check for a new firmware file on every reset. It only checks after bootloader entry, either via user request (double reset, button) or when the application area is empty. There are multple reasons why Katapult does this:

1. Initializing the SD Card can take time, in some cases several hundred milliseconds. Katapult seeks to minimize the reset delay. In addition, this delay can interfere with Katapult's double reset functionality.

2. During normal operation applications that use the SD Card will receive it in a pristine power on state. Even though Katapult makes every effort to return the SD Card to its original state before exiting, one of Katapult's goals is to launch the application as if the bootloader is not present....that is, all registers and peripherals are in their default power on state.

I have done quite a bit of local testing, however more testing would be welcomed.

In addition to SD Card support, this PR contains some changes to flashtool.py that have been previously requested.

• For USB devices, Katapult will now detect if device IDs report that Klipper is running on the MCU, and if so it will request that Klipper enter the bootloader. The -r option can be used to exit before programming if that is desired.
• The -r option also works with UART devices. It isn't possible to detect whether or not a UART device is running Klipper, so the bootloader request cannot be automated prior to programming.
• If the firmware file name passed to flashtool.py is klipper.bin, the tool will attempt to extract Klipper's data dictionary from the binary. If the dictionary contains an MCU variant that differs from the variant reported by Katapult, then a warning is printed to the console. Katapult will not abort the upload, but the user can use this information to build and flash the correct variant if necessary.
• Fixed a programming delay for some STM32 variants configured to flash via USB. This delay was introduced when syncing with Klipper's latest code base that included double buffering.

[VinnyCordeiro]

What is the state of this PR? This feature would be very useful.

[Arksine]

@VinnyCordeiro Good question. I recently rebased against the rp2xxx changes and at least the rp2040 still seems to work. I don't have a rp2350 to test.

I pushed this branch to gauge interest in this feature, with the hope that several individuals would volunteer for testing. This addition may require significant maintenance, and I don't want to merge it if:

1. The overall interest is low
2. I don't have positive feedback from multiple testers across the platforms supported by Katapult. SD Card updates must be reliable. There must be no regression with updates over CAN, USB, or UART.

I didn't announce this PR, so perhaps no one (but you) has noticed it. I'll see about doing so, in the meantime I'll leave it here for further feedback.

Edit: FWIW, I did cherry pick most of the changes to flashtool.py. They are now available in master.