Rewrite MotorController to be abstract and implement specific instances of Talon and Victor motor controllers

[snowsignal]

This PR closes #54.

Here is a short summary of the changes:

• MotorController is now an abstract class, with a handful of abstract methods that need to be overridden by child classes. It no longer takes any parameters in its constructor.
• VictorMotorController and TalonMotorController are both child classes of MotorController. It is still possible to have motor controllers of one type follow a different controller type, i.e. a TalonId could be passed in as a follower ID to a VictorMotorController class.
• motorController is a function that will create a motor controller depending on the specific MotorId type passed in.

These changes will make it much, much easier to implement a simulated motor controller and future types of motor controllers. I haven't run this through a linter yet, so styling could be off. Let me know what you think.

[snowsignal]

Alright, I also added the PhoenixMotorController subclass and moved a bunch of functions that couldn't be generalized for any motor controller into that subclass. The inheritance tree looks like this:

              MotorController ------------------------
              |                                      |
         SimulatedMotorController         PhoenixMotorController
                            --------------------------- | ---------------
                            |                                           |
                  TalonMotorController              VictorMotorController

SimulatedMotorController doesn't exist yet, but I'm showing where it would go.

[snowsignal]

I know this isn’t a priority issue, but it would be nice to get this reviewed + merged soon so I can start fixing the related issues.

[mckelveygreg]

@Jamdan2 Can we try running this branch on the robot soon? @InquisitivePenguin Would you also be able to update this year's competition code to reflect the new API?

[gnawinganimal]

Just a thought: should we change the motorController function to just motor? I feel like a helper function like that should be nice and short.

[gnawinganimal]

Haha just realized there was a problem with this. My bad.

[mckelveygreg]

@Jamdan2 Do we have plans of merging this before competition?

[snowsignal]

@mckelveygreg sorry for the late response, but yes, I can rewrite this year's code to work with the API.

@Jamdan2 You're right, but that's an implementation detail for when we implement simulated motor controllers. For now though, I'll create the ActualTalonMotorController subclass.

[gnawinganimal]

We need to share code between the actual motor controllers because they do almost the exact same thing, but we also need to the simulated and actual motor controllers to be treated as equals by the compiler... I'm gonna be honest I'm really wishing kotlin had rust's impl statement right now

[snowsignal]

Kotlin doesn't need impl because you can used abstract classes directly. We can just use TalonMotorController to work with both simulated and actual talon motor controllers. The fact that the actual Talon and Victor motor controller classes shared a lot of their code could be considered redundant, but it allows for more flexibility and makes more sense from a design perspective.

[gnawinganimal]

That's true. I suppose having duplicate code here is more convenient than avoiding it.