flipperzero: SPI interface

[str4d]

No description provided.

[QuantumEF]

Something I wanted to add here since I have book looking into this:
There seem to be 2 physical busses denoted as "bus_r" and "bus_d"
Because of this, I think there should be 2 SPIBus structs of some sort, one for "bus_r" and the other of course "bus_d" each implementing the SpiBus trait from the EmbeddedHal crate. Of course I still am not sure how it should be gone about implementing the SPI device trait. Based on what I am seeing, it might be best to implement each device with the SPI Bus trait since it seems like the higher level function calls that are exposed use the lower level items to lock the furi_hal_spi_bus_r_mutex "in targets/f7/furi_hal/furi_hal_spi_config.c"
As mentioned in a different post elsewhere, I am willing to help out with this. I probably need someone to help me understand how the bindings work, because it might be useful to try use and expose lower level function calls and static variables.
Further, based on how function calls like furi_hal_spi_bus_tx they are already using some sort of spin lock for transmitting data, so it would make sense to expose those calls with the non-blocking crate to provide an async interface.