Implement ACCELERATION_CLOCK.

This was tried a lot, with the following results:

1. Doing acceleration calculations (and later, curvature
   calculations) in an clock based interrupt instead of
   the step interrupt is an excellent idea. Achievable
   step rate raised from about 16.000 steps/second
   to 48.000 steps/second.

2. The approach to calculate desired speeds from movement time
   did work not so well. While it's possible to keep geometrical
   accuracy (continue at minimum speed or stop before decelerating
   to full stop in case the timing doesn't match), timing
   calculations are way to inprecise to match a movement's end
   within +- one step. Missing the movement end by more than 10
   steps was observer regularly.

3. Major reasons for 2. are apparently inprecise distance
   and timer calculations. Even accumulating just 1% of
   inprecision means more than 100 missed steps at the end
   of a long move.

4. To avoid 2., the next approach shall turn back to calculate
   speeds based on executed steps, like it was done in the step
   interrupt.

ACCELERATION_CLOCK is an approach different from the other ones.
Acceleration isn't calculated as part of the step interrupt, but
on clock based intervals (every 1ms or 2 ms). This not only
allows to do these calculations with 16 bit integers, it also
reduces the number of these expensive calculations at high speeds.
The step interrupt becomes very lean, doing only Bresenham
calculations, and should allow much higher step rates (several
steps can be done per acceleration calculation). 500 to 1000
speed calculations per second should be more than sufficient
to give a smooth ride.

It should be possible to combine this with ACCELERATION_TEMPORAL
to give equally spaced steps for _every_ stepper for an even
smoother ride.

More ACCELERATION_CLOCK.

ACCELERATION_CLOCK: add more refinements and debug code.

For yet unknown reasons, this strategy falls far below
expectations. Configured to 1280 steps/mm, the code works
for up to about 500 mm/min, only. ACCELERATION_RAMPING does,
despite the expensive acceleration calculation in the step
interrupt, manage to move 760 mm/min.

For finding the cause, I tried to comment out virtually all
code out of dda_step() as well as the clock interrupt. Just
Bresenham for the X-axis and setTimer() left, the code still
acts funny at pretty much the same feedrates. No enhancement
at all.

The debug code currently put in sends a 's' on every step
interrupt, a '.' on every clock interrupt. At higher speeds,
one should see one '.' every 20 's' or similar. However,
from time to time one sees consecutive clock interrupts,
apparently step interrupts fail to happen in some
situations.

The good thing: acceleration works reasonably fine now, the
situation with clock ticks, and along with them, speed changes,
happening more often than actual steps seems to be solved. In
earlier code, the first speed calculation right after movement
start caused a long pause, leading to something like a delayed,
unaccelerated movement.

Get ACCELERATION_CLOCK finally working. Yikes!

The problem was: the step interrupt unlocked interrupts and
if this resulted in a rush of pending other interrupts,
it took a looong time until the step timer was set again.