Make encoder classes unit-aware

[calcmogul]

Is your feature request related to a problem? Please describe.
We currently have Encoder, AnalogEncoder, and DutyCycleEncoder. None of them are unit-safe.

Describe the solution you'd like
To facilitate strong unit typing, we should split them all into linear and angular versions. I mocked up an API in C++ but never finished implementing the internals.

https://github.com/calcmogul/allwpilib/tree/_ref-new-encoder-api

[Daniel1464]

For the java version, would it be a good idea to include methods for returning stuff in the java units library, or should the only return value be doubles?

[calcmogul]

In Java. we've been offering getters and setters for both doubles and units. It's not ideal, but the Java units library just wasn't performant enough on the roboRIO for us to not offer an escape hatch. The units library got rewritten for 2025, so maybe units-only will work out better this time?

[Daniel1464]

Sure then. I don't think the units api rewrite does anything on the performance side of things though(just adds support for more methods that weren't possible w/ java's generics system).

[calcmogul]

Another option is just delaying this until 2027 when we get a more powerful processor and better garbage collectors (the more modern GCs don't support ARM 32-bit).

[Daniel1464]

Thinking about it, I think that for java we can probably mimic the simulation classes' methods(getVelocityRadPerSec(), getPositionRad()) as well as a getPosition() method that returns an Angle