Add gnuplot script to explore approximate_distance.

Error is less than 5% for explored range [0,200000].
approx_distance: much more research into dist approximation

approximate_distance.plot now derives the appropriate values to
be used for 8-way fine-tuning of the fast distance approximation
algorithm.  It produces 3 graphs:

  * A unit circle chart showing the locations of the 8
    sample points chosen for the algorithm.

  * A 2D graph of the measured actual error values using the
    derived values and the approximation algorithm with X
    fixed at 10000 and Y along one axis.  Note the scale
    of this graph is in percent.  The y-axis ranges from 0 to
    0.4%.  The maximum error is less than 0.15%.  That is,
    when the actual distance is 100000, the approximated
    value will be between 99850 and 100150.

  * A 3D graph of measured actual error values for all X and Y
    between 0 and 2000.  One of these graphs is zoomed in to show
    the noise of the low level, and another one is zoomed out
    to show just how mirror-smooth it really is.
approx_distance: Improve accuracy of 2d and 3d funcs

Fine-tuning the approx-distance 2d function gives accuracy better
than 99.7% in all cases.  Extending this to the 3d version gives
it also accuracy better than 99% in all cases.  This is an
improvement on the old code which achieved accuracies better
than 95% in most cases.
dda: Convert TARGET axis vars to array.

In preparation for more efficient and scalable code using axis-loops
for common operations, add two new array-types for signed and unsigned
32-bit values per axis. Make the TARGET type use this array instead of
its current X, Y, Z, and E variables.
dda: Convert more axis variables to arrays.

Many places in the code use individual variables for int/uint values
for X, Y, Z, and E.  A tip from a comment suggests making these into
arrays for scalability in the future. Replace the discrete variables
with arrays so the code can be simplified in the future.
um_to_steps_*: convert to generic implementation

A generic implementation here will allow callers to pass the target axis
in as a parameter so the callers can also be made more generic.
dda: Move axis calculations into loops.

Clean up code to reduce duplication by consolidating code into
loops for per-axis actions.
home: Reduce duplication with axis arrays
Remove obsolete um_to_steps_[xyze]
datalog: show traced data as signed ints, not unsigned
Rename confusing variable name

'all_time' sounds like forever to me, but this variable really
tracks the last time we hit one of "all the axes".  It sticks
out more now in looping, so rename it to make sense.
Trivial cleanups

Move some code around, fix some formatting, and hide a couple
of variables when they're not being used.
Exponential path planning

Experiments with exponential path planning, from this paper:
http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=6584209
WIP: more experiments with velocity approximation
WIP: Linear velocity paths in accelerate_temporal
Simulator: do not exit until dda queue is empty
WIP: LinearVelocity experiments
Flesh exponential planner research

exponential.c will produce two plots of velocity and position which
appear to be accurate.  Plot it on gnuplot like this:

  plot "exponential.out" using 2:3 with lines, '' u 2:4 with lines

Issue 1:
The position plot is based on separate acceleration calculations
from the velocity one.  We want instead to have a piece-wise integration
of the velocity profile to make up the position calculation.

Issue 2:
We use floating point everywhere here.  We need to use integers if we
want to port this into Teacup.
More: Flesh out exponential planner research

exponential.c will produce two plots of velocity and position which
appear to be accurate.  Plot it on gnuplot like this:

  plot "exponential.out" using 2:3 with lines, '' u 2:4 with lines

Now suports piece-wise integration of the velocity profile to make up
the position calculation.

Issue 1:
When we cannot reach vmax, we do not try hard enough.  The move gets
"blended" by rampup/rampdown overlap severely.  This is not a problem
for our 'exponential' linear approximation plans, but it does get in the
way of testing this implementation.

Issue 2:
We use floating point everywhere here.  We need to use integers if we
want to port this into Teacup.
More: Flesh out exponential planner research

exponential.c will produce two plots of velocity and position which
appear to be accurate.  Plot it on gnuplot like this:

  plot "exponential.out" using 2:3 with lines, '' u 2:4 with lines

Now suports piece-wise integration of the velocity profile to make up
the position calculation.

When we cannot reach vmax, we adjust vmax so it is reachable without any
overlap.  This may not be needed for 'exponential' linear approximations.

TBD:
We use floating point everywhere here.  We need to use integers if we
want to port this into Teacup.