(Proposal) Convert PathSequenceAuto from Builder pattern to procedural code

[rcahoon]

Description

About the same amount of code as before, but this allows you to more flexibly insert logic between the steps of the path. For example, this style makes it more natural to write things like

runPath(context, "move to the next note");
if (cameraSeesThatNoteIsPresent()) {
    context.runSync(new PickupNoteAndShoot());
}
runPath(context, "move to the next note");

while (!cameraSeesThatNoteIsPresent()) {
    runPath(context, "move forward a bit in case the note is further than we thought");
}
context.runSync(new PickupNoteAndShoot());

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Be detailed so that your code reviewer can understand exactly how much and what kinds of testing were done, and which might still be worthwhile to do.

• Unit tests: [Add your description here]
• Simulator testing: [Add your description here]
• On-robot bench testing: [Add your description here]
• On-robot field testing: [Add your description here]

[rajitzg]

Makes sense and looks good (in hindsight this is way simpler and less limited than what I had before). We can probably test this along with the runSync changes (although both look like they should work perfectly fine).

[rcahoon]

[Tangent] What you had is actually quite similar to the way that WPILib composes their Commands together, so it's a valid approach -- but as it gets built out to handle more use cases, you sorta have to recreate your own mini programming language interpreter inside Java. (Which is fun project to work through, if you want a hobby project over the summer: you already have the "named block of statements" aka simple functions; the next steps would be if-then-else statements, loops, and then variable assignment.) The idea behind the Procedures approach is that Java already exists as a programming language that we can use, so let's just use that.