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.

* The GTK version logs additional warnings, so we cannot
  match verbatim against stderr.
  Instead we only look for a line beginning with `Warning:` or `Error:`.
* We now also test info messages (`1^A`).

* 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.

* This could have been in ring.c, but in the future we may want to script
  the behavior in case recovery files are detected.
* The warnings are currently written as user messages, which looks
  ugly in interactive mode.
  Once n^A is supported, we can write them as regular warnings, though (FIXME).