Add fallback mechanisms for SPI peripherals

[PatrickKa]

Description

We have startup checks to see if the SPI peripherals (FRAM, EPS, Flash, and RF) are working. If there is a problem with any of those, except for the RF module, we still want to run our SW. Therefore, we need to check if a peripheral is working before we use it and, in case it isn't, have some fallback implementation that gets executed instead.

Fallback mechanisms for SPI peripherals:

• RF: We are pretty much dead, so the only thing we can do is reboot, maybe with a little delay. This is covered by Add SpiSupervisorThread #268.
• FRAM: Persistent State and Telemetry Memory is stored in RAM instead. The size of the Telemetry Memory will be drastically reduced to save memory. The sizes of the EDU queue and status history will also be decreased. To implement this, the persistent variables, EDU program queue, EDU program status history, and Telemetry Memory should all have an internal "cache" that is always used to store the data written to the FRAM. If the FRAM fails, the values are then also read from this "cache" instead. Since nothing that builds on top of the FRAM is implemented, yet we can do it right the first time, meaning that this is covered in Add abstraction for storing persistent variables #202, Move EDU program queue to FRAM #203, and Add abstraction for FRAM ring array #323.
• Flash: We cannot implement the COBC File System in RAM or anywhere else, so we basically cannot use the file system. Without it, it makes no sense to execute EDU programs, so this also disables the EDU (I already added a check in the EDU power management thread for this on miro, so this is covered with Update/finish EDU power management acc. to PDD #53). We still need to provide "empty" fallback implementations for the file system code, though, because we can still receive GS commands that want to read a file or something. These empty implementations should probably be for the highest-level functions of the COBC File System and return successfully even though write does literally nothing, and read returns an empty array or maybe a single byte that is zero. Those functions are not implemented yet so we just do it right the first time, meaning that this is covered in Add functions to store EDU programs and results #216, Add integrity check for EDU programs and results #217, Add functions to remove EDU programs and results #218, Add functions to read EDU programs and results #219, and Add functions to check available EDU programs and results #220.
• EPS: Add fallback mechanism for EPS #295