* The terminal's default foreground and background colors
  are now used by default (`sciteco --no-profile`), so SciTECO
  integrates naturally into all terminal color schemes, even
  dark-on-bright ones.
* The default Scintilla colors use only 0x000000 (COLOR_BLACK) and 0xC0C0C0 (COLOR_WHITE)
  now.
* You can use `7EJ` to configure the default colors in color
  schemes or your profile.
  All existing color schemes had to disable default colors
  (`-1,-1,7EJ`) since they wouldn't look well otherwise.
* You may add `-1,7EJ` to ~/.teco_ini when using a terminal emulator
  with a washed-out palettized COLOR_BLACK.
  We cannot detect the terminal's default colors automatically.
* Scinterm updated to v6.0.
  We require a not-yet-upstreamed patch:
  https://github.com/orbitalquark/scinterm/pull/40
* In fact, we might decide not to support default colors at all in Scinterm,
  so this feature should be considered experimental.

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

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

* We fork after command line arguments have been parsed, which
  is after gtk_get_option_group() has been called.
  This means that GTK was already initialized and it wasn't safe
  to continue after forking.
* As a workaround, we now re-exec with the original argv array,
  so GTK can be properly reinitialized.
  Since we did not remove `--detach` from argv (and that would be
  nontrivial), it would fork again endlessly,
  so we use an environment variable
  $__SCITECO_DETACHED to guard against recursive forks.
* Also, do not close stdin/stdout/stderr if has been redirected
  to a file, so you can now e.g. call `gsciteco -d >some-file`.
* This was broken since v2.5.0.

* An empty message line would actually contain "(Unnamed)".
* Info popups must discern the "(Unnamed)" string (e.g. a file with that name)
  from the actual unnamed buffer since when clicking the unnamed buffer, you
  must insert nothing (`EB$`). Therefore, the unnamed buffer is represented
  as an empty string. "(Unnamed)" is just a placeholder for rendering.
  This was carried over into TecoGtkLabel which always rendered the empty string
  as "(Unnamed)".
  But TecoGtkLabels are used for the info and message lines as well.
* Therefore the fallback/placeholder string is now configurable per label.
* On the downside, this wastes one more machine word per TecoGtkLabel.
  The alternative would have been to use {NULL, 0} as the representation
  for unnamed buffers, so you can actually discern the empty string from the
  unnamed buffer representation.
  However it feels wrong to have this kind of info-popup-specific handling
  in a more generic label widget.
  Also, for consistency we'd have to touch the Curses UI as well where
  the unnamed buffer is also currently internally represented by empty
  strings (as opposed to NULL).
* Regression introduced by 0c89fb700957e411885e7e7835e15f441e8b5e84,
  so it was in v2.5.0.

This is useful to launch from a terminal without "blocking" this terminal.
There are tools like nohup and daemonize (BSD) to do the same, but having it
builtin is shorter to write.

* When passing a struct that should not be modified, I usually use a const pointer.
* Strings however are small 2-word objects and they are often now already passed via separate
  `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well.
  A teco_string_t will usually fit into registers just like a pointer.
* It's now obvious which function just _uses_ and which function _modifies_ a string.
  There is also no chance to pass a NULL pointer to those functions.