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.

Traumflug notes:

- Did the usual conversion to spaces for changed lines.

- Added X = 0 to the enum. Just for peace of mind.

- Excellent patch!

Initially I wanted to make the new array an anonymous union with the
old variables to allow accessing values both ways. This way it would
have been possible to do the transition in smaller pieces. But as
the patch worked so flawlessly and binary size is precisely the
same, I abandoned this idea. Maybe it's a good idea in other areas.
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.
home.c: don't move to zero after homing to max endstop.

This can be counterproductive if the actual zero point is
outside the available build room. For example, if an additional
bed probing is going to happen. It also costs quite some
time on the Z axis. If you actually  want this behaviour,
send a simple G0 XYZ after homing.
home.c: no need to turn off Z axis here.

This is done in dda.c already, see dda.c, line 678.
DDA: convert um_to_steps_* 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.

Traumflug notes:

Split out application of the new implementation in dda.c into its
own commit.

This actually costs 128 bytes, but as we can access axes from within
a loop now, I expect to get more savings elsewhere.

Interestingly, binary size is raised by another 18 bytes if

  um_to_steps(int32_t, enum axis_e)

is changed to

  um_to_steps(enum axis_e, int32_t)

even on the 8-bit ATmega. While putting the axis number to the
front might be a bit more logical (think of additional parameters,
the axis number position would move), NXP application note
AN10963 states on page 10ff, 16-bit data should be 16-bit aligned
and 32-bit data should be 32-bit aligned for best performance.
Well, so let's do it this way.
DDA: use new generic um_to_steps_* in dda_new_startpoint().

This was contributed by Phil Hord as part of another commit.

It saves 168 bytes, to it more than outweights the overhead of
introducing a generic implementation already.
DDA: Move axis calculations into loops, part 1.

Clean up code to reduce duplication by consolidating code into
loops for per-axis actions.

Traumflug notes:

Split this once huge commit into smaller ones for ease of
reviewing and bisecting (in case something went wrong).

Part 1 is to put dda_create() distance calculations into loops.
This reduces binary size by another whopping 756 bytes.
dda_maths.h: remove now obsolete um_to_steps_[xyze].
DDA: Move axis calculations into loops, part 2.

Clean up code to reduce duplication by consolidating code into
loops for per-axis actions.

Part 2 is moving maximum speed limit calculations into loops.
Binary size another 160 bytes smaller.
DDA: Move axis calculations into loops, part 3.

Clean up code to reduce duplication by consolidating code into
loops for per-axis actions.

Part 3 is moving fast axis detection into a loop.
Binary size 84 bytes smaller.
DDA: Move axis calculations into loops, part 4.

Clean up code to reduce duplication by consolidating code into
loops for per-axis actions.

Part 4 is move ACCELERATION_TEMPORAL's maximum feedrate limitation
into a loop. Not tested, binary size change unknown.
DDA: Move axis calculations into loops, part 5.

Clean up code to reduce duplication by consolidating code into
loops for per-axis actions.

Part 5 is move ACCELERATION_TEMPORAL's step delay calculations
into loops. Not tested, binary size change unknown.
Rename all these new PROGMEM variables to end in _P.

Should be done for temptable in ThermistorTable.h, too, but this
would mess up an existing users' configuration.

This tries to put emphasis on the fact that you have to read
these values with pgm_read_*() instead of just using the variable.
Unfortunately, gcc compiler neither inserts PROGMEM reading
instructions automatically when reading data stored in flash,
nor does it complain or warn about the missing read instructions.

As such it's very easy to accidently handle data stored in flash
just like normal data. It'll compile and work ... you just read
arbitrary data (often, but not always zeros) instead of what you
intend.
Configuration: move DEBUG_LED definition.

Eventual debugging LEDs aren't part of the CPU, but part of the
electronics. Accordingly, define it in config.*.h, not in
arduino_*.h (which would be better named something like
"atmega_*.h).
run-in-simulavr.sh: run SimulAVR a bit more verbose.

SimulAVR doesn't always work exactly the way it should, so looking
at the command line it's started with is a first debugging step.
run-in-simulavr.sh: start signals undefined.

Also a few aesthetical corrections.
run-in-simulavr.sh: add support for timing measurements.

The idea is simple: if you want to time a portion of code
precisely, turn on the Debug LED (see config.h for
DEBUG_LED_PIN) at the start of sequence and turn it off when
done. Running this in SimulAVR, you have two flanges precise
to the clock cycle which exactly reflect the time taken to
run this code sequence. Ideally, you run this code n a loop
to get a number of samples, if it doesn't run in a loop anyways.

Time taken can then be measured in GTKWave. For convenience and
for a better overview, run-in-simulavr.sh also extracts all the
delays into it's own signal, so it can be viewed as an ongoing
number.
run-in-simulavr.sh: add statistics output for LED On Time.

As it's still a bit cumbersome to go through the whole .vcd file
to find the highest delay between On and Off, do this search
automatically and output an statistics. Can look like this:

  Statistics (assuming a 20 MHz clock):
  LED on occurences: 838.
  Sum of all LED on time: 262055 clock cycles.
  LED on time minimum: 306 clock cycles.
  LED on time maximum: 717 clock cycles.
  LED on time average: 312.715 clock cycles.

This should give an reasonable overview of wether and roughly
how much a particular code change makes your code slower or
faster. It should also show up showblockers, like occasionally
huge delays.

BTW., the above data was collected timing the step interrupt when
running short-moves.gcode with the current firmware.
heater_sim.c: Note that the heater isn't implemented in the simulator.
dda_maths.h: Add comment on units of C0.