Move endstop handling into a time-based procedure.

Before, endstops were checked on every step, wasting precious time.
Checking them 500 times a second should be more than sufficient.

Additionally, an endstop stop now properly decelerates the movement.
This is one important step towards handling accidental endstop hits
gracefully, as it avoids step losses in such situations.
dda.c: fix ACCELERATION_RAMPING #ifdefs.
Implement ACCELERATION_CLOCK.

For now, this is a draft, only.

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.
timer.c: add re-entry protection for the clock interrupt.