Corrected v slope and dsteps slope

These work and for these limited test cases, the number of steps
works out, too.  But step predictions are poor and the real-time
integration is frenetic for now.  There may be cases where a late
dstep causes two quick steps in succession, still.  I'm trying to
work those out in the next commit.
Clean up printf warnings
WIP: First crack at genius plan

Not working like I want.  Something buried in the math?
WIP: Short circuiting didn't help much
Fix makefile to match new plotted data

Also, normalize makefile a bit
Clean up old float routines

TS was done with floats when it was no longer needed.

Trapezoidal position was done with floats and it was introducing
errors.  These showed up as errors elsewhere in the code, but in
fact it was the check-routine (trap-pos) that was wrong.  Argh!
Remove vestiges of "genius" idea, not currently used.

Seems like this still has merit.  For example, if we find that
remainder is huge after a step, we must not be stepping fast
enough so we should bias our next step forward a bit.  But if
we do that we risk compensating for error all at once and causing
a missed step.  Best not to risk that unless we can always manage
to keep remainder very low by fine-tuning dStep very well.
fixup: Mostly trivial cleanup
Make vDelta include the whole math_period

Trying to integrate only at step-times was causing us to accumulate
too much error.  Accumulate per cycle instead and do the math at
interrupt time.  This involves multiplication and division and so
is probably too expensive for real AVR implementation.  But I hope
to solve that in the future by some clever accumulator/divider trick.
For now, this provides the final bit of needed accuracy, so I plan
to keep it going forward in some form.

Also, clean up some time windows at various places.
Make remainder a signed value so it can go below zero if we
decide to step a little early.
Trivial cleanup