Thermistortableless: instead of a divide, multiply with the inverse.

Saves about 300 clock cycles.
Prepare code to do temp calculations, only.

Runs nicely in the simulator.
More integer math.

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.
Implement the logarithm algorithm used in the HP-35 calculator.

Remember the HP-35? It was the world's first pocket calculator
doing trigonometric math, starting the end of slide rule usage.

It's an brilliant algorithm, so let's keep it.
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.

As another steps to become fully integer, do normalisation as such.
Go entirely integer.

Performance is back:

LED on time minimum: 1644 clock cycles,
LED on time maximum: 6506 clock cycles,
LED on time average: 5084,92 clock cycles,
int_log(): loop up the multiplication part.

Makes it even a bit faster:

  SIZES             ATmega,,,  '168    '328(P)    '644(P)    '1280
  FLASH : 20222 bytes          142%       66%        32%       16%
  RAM   :  2169 bytes          212%      106%        53%       27%
  EEPROM:    16 bytes            2%        1%         1%        1%

  LED on time minimum: 1646 clock cycles,
  LED on time maximum: 6345 clock cycles,
  LED on time average: 4920,21 clock cycles,
What a small change can make a difference!

This change saves a whopping 2200 clock cycles on average.

  FLASH : 20172 bytes          141%       66%        32%       16%
  RAM   :  2169 bytes          212%      106%        53%       27%
  EEPROM:    16 bytes            2%        1%         1%        1%

  LED on time minimum: 1646 clock cycles,
  LED on time maximum: 3165 clock cycles,
  LED on time average: 2734,88 clock cycles,
More optimisation.

This ATmega is apparently good at multiplication.

  FLASH : 20232 bytes          142%       66%        32%       16%
  RAM   :  2169 bytes          212%      106%        53%       27%
  EEPROM:    16 bytes            2%        1%         1%        1%

  LED on time minimum: 1646 clock cycles,
  LED on time maximum: 2714 clock cycles,
  LED on time average: 2486,61 clock cycles,
int_log(): fix bit shifting.

One can't shift negative by amounts ...
preprocessor_math.h: add EXP().

EXP() is a preprocessor macro version of exactly what exp() in
avr-libc provides. Tested with a few arbitrary numbers and the
numbers used for thermistor value conversion. Should be
accurate for all numbers which can be casted to an (u)int32_t.