IMU: Initial R3 Driver Implementation

[ETSells]

**Requester: @ETSells **

(Non-developer requests only): Is your feature request related to a problem? Please describe.
With the IMU and barometer, we'll have the two main flight computer sensors up and running.

Describe the solution you'd like
I would like at least blocking APIs for data retrieval from the IMU (but a non-blocking form would be preferred). Init interface should be blocking.

We could retrieve euler gyro readings like rev 2, but I would encourage us to use the SFLP (sensor fusion low power) interface in order to get quats.

Datasheet: https://www.st.com/resource/en/datasheet/lsm6dsv320x.pdf

Performance Spec:
For our initial implementation, the target is 1 kHz (read accel and gyro data in under 1 ms). Configure an ODR of 1.92 kHz.

Describe alternatives you've considered
N/A

Additional context
Add any other context or screenshots about the feature request here.

Points of Contact
Add a tag for the component owners, leads, and/or a senior engineer to serve as primary point of contact.

[ETSells]

probably the most bonkers initial task

[ETSells]

Bulk change: Pushing back R3 issues one week due to spring break.

[ETSells]

STM appears to provide a platform independent driver for this IMU. We could try the following:

1. Link PI driver as a submodule in lib.
2. Create a facade layer in driver that uses those procedures for reg reads/writes. We care about these two interfaces:
   2a. IMU init (set up configs, set up facade layer)
   2b. IMU read (maybe accel and quats? we may not need raw gyro data at all)
   2c. IMU config for certain options we want to change at runtime (low-G to high-G? ODR/OSR changes? low-power?)
3. Set up the register read/write alias to use blocking SPI I/O functions for init, and have an option to switch out for IT/DMA I/O.

Will attempt this myself if I make good enough progress on flash, but someone can steal it from me first if they want.

[MasterUser43]

https://github.com/STMicroelectronics/lsm6dsv320x-pid

[ETSells]

🔥 yeah exactly. license compatible and everything, so hopefully we just need shallow wrappers for it.

the weird part here is gonna be switching blocking <-> nonblocking for certain APIs since the PI driver requires specific callbacks, and you'll probably have to set up that logic yourself. but hopefully since this has a ton of available APIs, we won't have to worry too much about weird sensor fusion setup things and can just use it.