Split pros crate into multiple smaller sub-crates

[Gavin-Niederman]

The current situation

Currently most of the code for pros-rs, excluding pros-sys, is all in one monolithic pros crate. This is less than ideal. Changing any code throughout the pros crate forces the entire thing to recompile, there is no easy way to show what parts of pros are supported in the simulator, and we cant easily make sure that async and sync code are seperated in the user's code.

What should change

The pros crate should still be the only crate a user should have to import, but the actual implementation should be split into multiple sub-crates. These crates could possibly include

• Pros-async for code involving the async executor and AsyncRobot trait.
• Pros-sync for code involving FreeRTOS tasks and the SyncRobot trait.
• Pros-sensors for code involving vex accessories and sensors.
  And more.

The pros-async and pros-sync crates should be locked behind features that are mutually exclusive to ensure that pros users are not mixing async and sync code together. Crates that aren't implemented in the simulator should be made to not compile on wasm32, providing a helpful error message that informs a simulator user that it isn't supported.

Possible disadvantages

Function inlining does not happen between rust crates without specific #[inline] macro attributes. This might make performance worse, but probably won't even be noticeable.