* You can now specify `--with-scitecodatadir` as a relative path,
  that will be interpreted relative to the binary's location.
* Win32 binaries already were relocatable, but this was a Windows-specific
  hack. Win32 binaries are now built with `--with-scitecodatadir=.`
  since everything is in a single directory.
* Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`.
  This is not crucial for ordinary installations, but is meant for AppImage creation.
* Since AppImages are now built from relocatable packages,
  we no longer need the unionfs-workaround from pkg2appimage.
  This should fix the strange root contents when autocompleting in
  AppImage builds.
* This might also fix the appimage.github.io CI issues.
  I assume that because I could reproduce the issue on FreeBSD's
  Linuxulator in dependence of pkg2appimage's "union"-setting.
  See https://github.com/AppImage/appimage.github.io/pull/3402
* Determining the binary location actually turned out be hard and
  very platform-dependant. There are now implementations for Windows
  (which could also read argv[0]), Linux and generic UNIX (which
  works on FreeBSD, but I am not sure about the others).
  I believe this could also be useful on Mac OS to create app bundles,
  but this needs to be tested - currently the Mac OS binaries are
  installed into fixed locations and don't use relocation.

* This API behaves very strangely and differently compared to UNIX/X11.
  When getting, it returns a trailing null for all clipboard contents
  (unless the clipboard is empty) and when setting, we apparently have to include it as well.
  At least since we cut it off when getting.
  Even more strangely, setting without the trailing null did work
  when pasting in external apps. (How they know when it's safe to throw
  away the trailing null is mysterious.)
* In other words, this fixes X~G~.

* Contrary to the Gtk documentation, the gtk_selection_data_get_length()
  already includes a trailing null, so we always inserted a bogus
  null char when using G~ or ^EQ~.

* added TECO_ERROR_CLIPBOARD for all clipboard-related errors

* ALL keypresses (the UTF-8 sequences resulting from key presses) can now be remapped.
* This is especially useful with Unicode support, as you might want to alias
  international characters to their corresponding latin form in the start state,
  so you don't have to change keyboard layouts so often.
  This is done automatically in Gtk, where we have hardware key press information,
  but has to be done with key macros in Curses.
  There is a new key mask 4 (bit 3) for that purpose now.
* Also, you might want to define non-ANSI letters to perform special functions in
  the start state where it won't be accepted by the parser anyway.
  Suppose you have a macro M→, you could define
  @^U[^K→]{m→} 1^_U[^K→]
  This effectively "extends" the parser and allow you to call macro "→" by a single
  key press. See also #5.
* The register prefix has been changed from ^F (for function) to ^K (for key).
  This is the only thing you have to change in order to migrate existing
  function key macros.
* Key macros are enabled by default. There is no longer any way to disable
  function key handling in curses, as I never found any reason or need to disable it.
  Theoretically, the default ESCDELAY could turn out to be too small and function
  keys don't get through. I doubt that's possible unless on extremely slow serial lines.
  Even then, you'd have to increase ESCDELAY and instead of disabling function keys
  simply define an escape surrogate.
* The ED flag has been removed and its place is reserved for a future mouse support flag
  (which does make sense to disable in curses sometimes).
  fnkeys.tes is consequently also enabled by default in sample.teco_ini.
* Key macros are handled as an unit. If one character results in an error,
  the entire string is rubbed out.
  This fixes the "CLOSE" key on Gtk.
  It also makes sure that the original error message is preserved and not overwritten
  by some subsequent syntax error.
  It was never useful that we kept inserting characters after the first error.

The following rules apply:
 * All SciTECO macros __must__ be in valid UTF-8, regardless of the
   the register's configured encoding.
   This is checked against before execution, so we can use glib's non-validating
   UTF-8 API afterwards.
 * Things will inevitably get slower as we have to validate all macros first
   and convert to gunichar for each and every character passed into the parser.
   As an optimization, it may make sense to have our own inlineable version of
   g_utf8_get_char() (TODO).
   Also, Unicode glyphs in syntactically significant positions may be case-folded -
   just like ASCII chars were. This is is of course slower than case folding
   ASCII. The impact of this should be measured and perhaps we should restrict
   case folding to a-z via teco_ascii_toupper().
 * The language itself does not use any non-ANSI characters, so you don't have to
   use UTF-8 characters.
 * Wherever the parser expects a single character, it will now accept an arbitrary
   Unicode/UTF-8 glyph as well.
   In other words, you can call macros like M§ instead of having to write M[§].
   You can also get the codepoint of any Unicode character with ^^x.
   Pressing an Unicode character in the start state or in Ex and Fx will now
   give a sane error message.
 * When pressing a key which produces a multi-byte UTF-8 sequence, the character
   gets translated back and forth multiple times:
   1. It's converted to an UTF-8 string, either buffered or by IME methods (Gtk).
      On Curses we could directly get a wide char using wget_wch(), but it's
      not currently used, so we don't depend on widechar curses.
   2. Parsed into gunichar for passing into the edit command callbacks.
      This also validates the codepoint - everything later on can assume valid
      codepoints and valid UTF-8 strings.
   3. Once the edit command handling decides to insert the key into the command line,
      it is serialized back into an UTF-8 string as the command line macro has
      to be in UTF-8 (like all other macros).
   4. The parser reads back gunichars without validation for passing into
      the parser callbacks.
 * Flickering in the Curses UI and Pango warnings in Gtk, due to incompletely
   inserted and displayed UTF-8 sequences, are now fixed.

* ^Uq however always sets an UTF8 register as the source
  is supposed to be a SciTECO macro which is always UTF-8.
* :^Uq preserves the register's encoding
* teco_doc_set_string() now also sets the encoding
* instead of trying to restore the encoding in teco_doc_undo_set_string(),
  we now swap out the document in a teco_doc_t and pass it to an undo token.
* The get_codepage() Q-Reg method has been removed as the same
  can now be done with teco_doc_get_string() and the get_string() method.

* Eg. when typing with a Russian layout, CTRL+I will always insert ^I.
* Works with all of the start-state command Ex, Fx, ^x commands and
  string building constructs.
  This is exactly where process_edit_cmd_cb() case folds case-insensitive
  characters.
  The corresponding state therefore sets an is_case_insensitive flag now.
* Does not yet work with anything embedded into Q-Register specifications.
  This could only be realized with a new state callback (is_case_insensitive()?)
  that chains to the Q-Register and string building states recursively.
* Also it doesn't work with Ё on my Russian phonetic layout,
  probably because the ANSI caret on that same key is considered dead
  and not returned by gdk_keyval_to_unicode().
  Perhaps we should directly wheck the keyval values?
* Whenever a non-ANSI key is pressed in an allowed state,
  we try to check all other keyvals that could be produced by the same
  hardware keycode, ie. we check all groups (keyboard layouts).

* All non-ASCII characters are inserted as Unicode.
  On Curses, this also requires a properly set up locale.
* We still do not need any widechar Curses, as waddch() handles
  multibyte characters on ncurses.
  We will see whether there is any Curses variant that strictly requires
  wadd_wch().
  If this will be an exception, we might keep both widechar and non-widechar
  support.
* By convention gsize is used exclusively for byte sizes.
  Character offsets or lengths use int or long.

* This is the same variable used by gtk3-nocsd, but we will now work
  even without preloading any libraries.
  Also, it turns out that gtk3-nocsd does not ship as a FreeBSD port
  and hasn't been updated in a long time.
* Setting this in .teco_ini wouldn't have been easy since the
  teco_interface_init() is called before any TECO code.
  Also, you might not even want disable this globally but depending
  on the window manager.
* Therefore, you are advised to `export GTK_CSD=0` in ~/.xsession.
* The --no-csd command line option is kept for the time being,
  but probably serves no more purpose.