Canned G-code: implement continuous replay of G-code stored on flash.
Canned G-code: fix reading flash memory.
Canned G-code: don't miss first character.
Canned G-code: setup right in config.h.

This works with Arduino IDE as well and should be easier to figure
for inexperienced users.
Canned G-code: distribute new config option to all templates.
preprocessor_math.h: fix errorneous comment.
Move clock stuff from timer.c/.h to clock.c/.h.

I guess that's where it belongs.
heater.c: add a hysteresis when using BANG_BANG.

Before, the heater would turn off and on at each tiny temperature
fluctuation. Or better: at every tiny analog voltage fluctuation.
config.*.h: distribute changed TEMP_HYSTERESIS description to all templates.
Prepare code to do temp calculations, only.

Runs nicely in the simulator.
Implement temperature calculation using floating point maths.

Performance so far:

Before, with ThermistorTable.double.h:
LED on time minimum: 1107 clock cycles,
LED on time maximum: 3198 clock cycles,
LED on time average: 2162,43 clock cycles,

Before, with ThermistorTable.single.h:
LED on time minimum: 741 clock cycles,
LED on time maximum: 1488 clock cycles,
LED on time average: 1364,6 clock cycles,

Direct calculation with Doubles:
LED on time minimum: 1206 clock cycles,
LED on time maximum: 5225 clock cycles,
LED on time average: 4950,59 clock cycles,
Instead of a divide, multiply with the inverse.

Saves about 300 clock cycles.
More integer math.

Also an integer logarithm algorithm which might be useful later.

Saves about another 300 clock cycles. We've closed half the gap
between a floating point calculation and a 100-entries table:

LED on time minimum: 1469 clock cycles,
LED on time maximum: 4523 clock cycles,
LED on time average: 4260,66 clock cycles,
Yet another bit closer to integer-only math.

No performance improvements, this time.

All this move towards integers has brought a small, but noticeable
change in results: large deviations for 2..8 and 0 or +/-.25 for 28+
Likely some rounding errors.
Use a polynomal and performance is back.

LED on time minimum: 1592 clock cycles.
LED on time maximum: 1778 clock cycles.
LED on time average: 1621.56 clock cycles.

Precision isn't that bad, either ...
These polynomals found by linear regression are very fast and nice,
but finding their coefficients is at least as complex as making
thermistor tables.

Thermistor manufacturers provide no such coefficients, only R0,
T0, Beta. Accordingly, turn back to find an algorithm
logarithm.

Nice thing: This algorithm the HP-35 pocket calculator used could
be implemented successfully. Right now, a nice demonstration is
coded.
Other than HP-35, choose 2 as target number. In theory, this
should be faster than target 10, but actually, it's worse:

With hp_35_log():
LED on time minimum: 1949 clock cycles,
LED on time maximum: 22478 clock cycles,
LED on time average: 14977,3 clock cycles,

With teacup_log():
LED on time minimum: 1949 clock cycles,
LED on time maximum: 24425 clock cycles,
LED on time average: 16669,5 clock cycles,
teacup_log() collect the result as 8.24 fixed point directly.

While this replaces additions/substractions, only, performance
is quite a bit better already:

LED on time minimum: 1937 clock cycles,
LED on time maximum: 16446 clock cycles,
LED on time average: 11528,6 clock cycles,
Spotted a small improvement: a 16-bit multiplication is sufficient.

LED on time minimum: 1879 clock cycles,
LED on time maximum: 16388 clock cycles,
LED on time average: 11470,6 clock cycles,
Move floating point entirely into teacup_log().

This required additional steps to use the full range of an uint32
and keep accuracy. Doing it this way, accuary is still excellent.