Remove VoltageController class in favour of just using MotorVoltageController (Potentially renaming MotorVoltageController to VoltageController)

[spacey-sooty]

The obsessive usage of abstractions is good for us in many cases but comes with a performance cost so shouldnt't be used without good reason. VoltageController is designed to be able to create a lot of different voltage controllers which inherit from it but we only have MotorVoltageController and I don't see any obvious reason to have any other VoltageControllers. To this end I'd suggest just removing it entirely and creating the MotorVoltageController as an individual class.

[JaciBrunning]

FWIW the cost of indirection in this case is near-zero since it's just a v-table lookup in the worst case - it wouldn't be accurate to say it imposes a performance penalty. The reason we originally had VoltageController as an abstract class was twofold:

• So it could be mock'd for testing purposes
• So you could override it with a simulated motor controller for desktop environments.

Most of this should be supported now through WPI and CTRE's simulation frameworks, but it's worth noting those didn't exist at the time of writing.

[spacey-sooty]

That makes a lot of sense. Since most of its already supported through WPI and CTRE frameworks for sim it's probably worth to split it either way for the sake of simplicity. I also guessed the performance cost would be mostly negligible but overall that probably makes this a low priority issue.