Imu traits take 2 - Githubissues

I added an imu trait. Originally I was thinking there would be a fused and unfused imu, but it makes far more sense for there to just be one imu trait generic on its associated type, and that type can be fused or unfused. Also there was disagreement before on how to name stuff, like whether its RawImu or Imu or FusedImu. This makes that no longer necessary because all imus are the Imu trait.

I also added a FusedImu struct that we can use to combine an unfused imu with a Fuser. The idea is that the Fuser is purely a math thing. It could be any fusion algorithm.

One thing that remains to be solved is where filtering comes into the picture. If possible I think we should punt that to a later design iteration, when we have a need for it. Its possible that FusedImu is the one without filtering, and FilteredFusedImu has filtering also, which also implements Imu<Data=FusedData>. I'm not really sure which is why I think we should deal with it later in favor of unblocking present work.

I did not touch any of the business logic of the current imu implementations (such as the bmi160) as I felt that was out of scope. The bmi160 should become an unfused type in a followup pr, and we should also refactor the nonblocking imu functions into async blocking ones, if we can figure out how to do that using proper async (might be hard, because most drivers use a non-async blocking api).

SlimeVR / SlimeVR-Rust

Imu traits take 2 #167