There's no power saving (sleep) yet, but the more complex code is not as
accurate and needs 10 bytes more than the simple busy wait.

delay_s() varies between 750 and 1000 ms. Not a big problem in our case
because the delay is not very critical and just delays periodic events.
So if everything is right the delay between these periodic events should
be always of the same length. But let's document this.

Not sure how I calculated 26 seconds, but 64 * 0.25 = 16.

This reverts commit 27f20a24.

First reason: There is one second darkness before beacon starts. This
looks not so nice.

Second reason: The compiler does crazy things and I'm too lazy to debug
this right now.

N=1 is not good for calibration. What am I doing here?!

This also refactors the fixed level table which is now a list of indexes
in the normal ramping table. This saves some memory because we have less
computations later.

Also ramping_up is now just signed ramp_direction.

We also consistently ramp into the direction of the initial brightness
(more or less, you'll see).

This allows changing the ramp value in short intervals.

This makes everything a bit more consistent.

It doesn't make lot of sense as it is not much lower than the normal
low, but requires 14 bytes of flash. It also conflicted with the strobe
mode. A similar mode can be achieved by setting "start on low".

Looks and feels great, but requires 20 bytes of flash!

We can go down to 1 with our slow PWM.

This is simpler than using the PWM overflow handler, prepares for power
saving and allows us to use different PWM frequencies without other
modifications.

It is now also used for moonlight mode.

Currently only 1s and 2s interval

Extends the strobe mode. If options.moonlight is set and options.strobe
is not, then the light will turn on alway in moonlight and after a
single tap it will continue with the default mode.

At least with the development board there is no visibly huge difference
in output, so this should be considered WIP.

This saves a lot of flash.

The previous level was too bright in dark environment. The new level is
currently shared with other uses and thus saves two bytes of flash.

This saves 12 bytes of flash.

Quickly measured with bench power supply.

This saves 8 byte.

If we assume that the config case in the switch statement is reached
before the user can tap a second time [1] there is no need to handle
overflow of fast_presses in a separate if statement. Instead it is
enough to set fast_presses to the current value minus one so that when a
possible next press of the power switch increments the counter again
this results in the same case.

This saves 6 bytes of flash.

[1] Which is unlikely because the execution time until this point is
much shorter than human repetitive finger movement, so only button
bouncing can be an issue and that would require other measures

If users want a strobe mode, they usually want it for defence purposes.
Thus it should be possible to enter it as fast as possible. If strobe is
enabled (first option if STROBE is compiled) the flashlight always
starts in a strobe mode. Then a single press of the power switch enters
the usual UI.

TIMSK0 is outside of lower 32 I/O registers and thus cannot be set via
sbi. This saves 4 bytes of flash.

Set a flag in the interrupt handler instead of checking the current tick
value.

Requires additional 14 bytes of flash...

Now we use registers in the function call area. But we don't use any
functions with many arguments, so this is not a problem and saves 56
bytes.

Costs 8 bytes of flash.