switched around the way we keep track of buffer slots

now there's an expected and a reported value so we don't overrun
the servo between status messages.

we also learned today that the servo won't report anything as being
in the buffer until you're actually moving. that is super frustrating!
debug print statements and commented out calls to send pvt segment

all the recovering from error code was commented out and that made
things actually work. I should either consider removing this code
all the way or figuring out why it is broken. it was written with
assumptions about the way we were going to use the buffer that are
no longer true.
be a lot more careful about exactly how we start moving.

now keep track of servo buffer readiness (doesn't actually work,
but it is a nice idea) and then make Motion figure out when to
actually start. making Motion call for the start is a good idea,
but because the servos don't report buffer status until after they're
told to start moving, the readiness is a bit of a bust. it should
be refactored into something more useful or just dropped all together.
changed sendPvtSegment.

now you're in charge of giving it the time you want the segment to be
for.

I also fixed the scary test mode so now it is really what we want math
wise. now it doesn't trip the power supply and crasy the machine
anymore, which is always nice.
hacks and terminal output.

this works around the annoying "no buffer state 'till we're already
moving" problem by just waiting some number of sync messages and going
for it. this is probably not an ideal way of making the robot go, so
something should be done.

also, there's enough error print statements in here to be really
annoying. they should probably go away...