* Instead of supporting only 16 predefined RGB placeholder
  values in Scintilla messages and styles, you can now use
  arbitrary RGB values and colors are allocated via the terminal
  on the fly.
  You no longer need to call 3EJ to change the default color
  palette.
* The placeholder RGB values are still available.
  Since you will usually want exact RGB values when using
  anything outside of the range of 16 default colors
  and the RGB placeholders will not always exactly correspond
  to their RGB value, you can now call `0,3EJ` to ignore
  the default palette and allocate all colors dynamically.
* Allows for more than 16 colors on the screen simultaneously.
  Also simplifies the solarized.tes color scheme.
  Since both Scinterm and SciTECO try not to touch the 16
  default colors, you also no longer have to deal with
  restoring the palette after program termination
  (which was never reliable anyway).
* Color schemes with non-default colors (solarized.tes)
  may now be broken on TERM=linux-16color (Linux VT)
  since Scinterm will get only 8 colors, but solarized.tes
  needs 16.

This was especially dangerous since the introduction of
a message level parameter, which could still be popped from
the expression stack in parse-only mode or during lexing.
This effectively broke n^A interactively in GTK.

* Had been broken since introduction in v2.3.0.
* This slowed down EQq<filename>$ on large files.

* signal() sets SA_RESTART by default.
* Some syscalls can theoretically block indefinitely.
  Even opening a special file could result in an indefinitely
  blocking operation, that should be interruptible.
  You must still poll teco_interrupted in these read() loops of course.
* Also makes sure that clipboard operations are interruptible
  even if $SCITECO_CLIPBOARD_GET blocks.
  Although I couldn't provoke problems in practice,
  I did observe hangs with xclip on Wayland on Linux,
  that could only be resolved by manually killing xclip.

* Scinterm was simply rendering them as black, thus effectively
  breaking the Linux and FreeBSD vts with terminal.tes.
* I was considering to render light black as white on 8-color terminals,
  so it's always readable.
  However, if you add in A_BOLD there is a good chance that the
  color will end up grey - at least it does in the virtual terminals (consoles).
* There is no need to use bright colors in the Scintilla view defaults.
  E.g. 0xFFFFF is "light white".
  However on 8-color terminals this will be rendered like white anyway.
  The new defaults are closer to what terminal.tes does.

* I.e. you can now log warnings and errors from SciTECO code as well.
* We do not need a version of ^A accepting code points, since this is
  supported by ^T already.

* SIGTERM used to insert the ^KCLOSE key macro.
  However with the default ^KCLOSE macro, which inserts `EX`,
  this may fail to terminate the editor if buffers are modified.
  If the process is consequently killed by a non-ignorable signal,
  we may still loose data.
* SIGTERM is used to gracefully shut down, so we now always terminate.
  Since we have recovery files, they are now dumped before terminating.
  This makes sure that recovery files are more up-to-date during
  unexpected but gracefull terminations.
* The same functionality is planned on Curses, but requires more fundamental
  changes (TODO).

Between calls to `^T`, the original key-press-event handler might
enqueue events, that we must first process and report with `^T`.
Otherwise it would be easy to provoke apparent double-reporting of keys after
input loops like `<^T:;>`.

* There was a logic error in teco_interface_getch() that caused Curses function key
  codes to be returned directly. These codes however are useless to macro authors and
  can be confused with codepoints. You cannot report function keys in the same "namespace"
  along with Unicode codepoints.
  They are now filtered out.
* Also make sure that Backspace and Return are reported as 8 and 10 respectively
  in all Curses variants.
  All control codes reported by Curses are passed down unmodified - in contrast to
  the command-line input handling. I.e. 13 is not normalized to 10.
* PDCursesMod/WinGUI may return bogus key presses, that also have to be filtered out
  as we already did in the main input handling.
  A function teco_interface_check_key() has been introduced.
* NOTE: teco_interface_blocking_getch() already makes sure that recovery files are dumped
  even when blocking in `^T`.

5 minutes was probably a bit too conservative.