Motion refactor

Today, each type of motion is a function declared in motion.h, such as motion_forward() and motion_corner(). Though motions do use common elements such as a linear trapezoidal motion profile calculator, sensors, and motors, there is still a lot of repeated code. Moreover, the code is hard to understand to the point that further development is difficult.

The first thing we need is a design discussion.

These are my initial thoughts, as discussed with @amiller27 and @aftersomemath this week. I started to play with what the code might look like in b74d063 (headers only).

It's a bit vague, but hopefully it makes some structure apparent.

... and worth noting that since that drawing, I've at least

• renamed Drivetrain to SkidSteerCar
• inserted a drive() function between Maneuvers and SkidSteerCar as the place where gyro and range get pre-baked into the LinearRotationalProfile

For anyone interested: Proof of concept for Straight on branch motion-test-1 (557058f).

I've convinced myself that the general structure for new motion is working. Now I need to straighten out the other maneuvers and tune everything. I found out our feed-forward tuning is currently awful, but I think we knew that :-)

Also worth noting. With encoders only, the robot drives way more smoothly than legacy motion. Depending on what we observe, we might want to investigate smoothing range and/or gyro errors.

New concept that I'm currently working on using "matrix" math. Will allow independent control and tuning of linear/rotational feed-forward/correction. Has plenty of errors and oversights, but I like where this is going.

This would replace SkidSteerCar, PointOnBody, and Wheel.

Worth noting, this issue will also involve #12 and #13. To tune new motion we'll need to tune feed-forward followed by PID for all components.

Straight and Pivot zig-zag proof of concept on branch motion-test-2 (9dc236c).