Extend common mechanisms to support simulation

[jamesdooley4]

Building upon #51, the common mechanisms should have configurable, known-good simulation implementations to make it fast to create a new subsystem that spins the motor in simulation in a reasonable manner. Using the motor movement to control movement of a MechanismLigament2d or a Pose3d would be left as an exercise of the consuming subsystem, since those depend implicitly on the specific robot design.

[kraftmulaney]

@jamesdooley4 , we tried a bunch of different ways to have known-good simulations of simple stuff. There's two primary ways to do it, and both leverage the wpilib Physics Simulations for elevators/motors/etc:

1. Use the wpilib Physics Simulations, and feed the outputs back into the Sim-wrapper classes that WPILib uses to allow you to set values on the motor classes your bot instantiates
2. Use an interface to have subsystems talk to "motors", "elevators", "winches", etc.

After a couple years of going back-and-forth, I think #2 is the MUCH cleaner way to go.

Here's the interfaces we use in Ramen:
https://github.com/RamenRobotics9036/Mochi2026/tree/users/ido/robotutilslibrary4/robot-utils/src/main/java/robotutils/pub/interfaces/simio

...and here's the reusable implementations of the Physics simulations using those interfaces:
https://github.com/RamenRobotics9036/Mochi2026/tree/users/ido/robotutilslibrary4/robot-utils/src/main/java/robotutils/sim

...And here's an example of the "real" implementation in a subsystem of one of the rollers we had:
https://github.com/RamenRobotics9036/Mochi2026/blob/users/ido/robotutilslibrary4/src/main/java/frc/robot/subsystems/intake/ArmIoReal.java