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

* teco_file_get_absolute_path() does not currently guarantee to resolve
  non-existent parts of the path.
  When opening a symbolic link to a non-existing file, it would only
  be created when writing out the file.
  The undo token to remove it, however would remove the original
  unresolved path.
  When rubbing out the EW, the symlink would get removed instead
  of the newly written file.
* We now resolve/canonicalize the path again immediately after
  opening the new file, which should ensure that it resolves.
* As an alternative, we might have also tried to reliably canonicalize
  non-existent symlinks. This however is tricky and there would have
  to be a break condition to guard against cyclic symlinke.
  In the end there is no guarantee to be able to resolve a path
  exactly like the OS does.
  Therefore, teco_file_get_absolute_path() was not touched,
  not even on UNIX.
* A test case was not added since it would rely on creating real symlinks.
  It wouldn't work on MSYS when `ln -s` falls back to hardlinks.
  Perhaps other non-UNIX platforms would have similar restrictions.

* Popup entries are added with expanded directory names, so we have to skip the
  expanded directory names from the clicked popup entries.

* Curses allows scrolling with the scroll wheel at least
  if mouse support is enabled via ED flags.
  Gtk always supported that.
* Allow clicking on popup entries to fully autocomplete them.
  Since this behavior - just like auto completions - is parser state-dependant,
  I introduced a new state method (insert_completion_cb).
  All the implementations are currently in cmdline.c since there is some overlap
  with the process_edit_cmd_cb implementations.
* Fixed pressing undefined function keys while showing the popup.
  The popup area is no longer redrawn/replaced with the Scintilla view.
  Instead, continue to show the popup.

* This is not simply determined at compile-time but queries the concrete path
  at least on Windows and OS X.
* The Windows implementation is kind of hacky and relies on undocumented behavior.
  It's also not even tested yet!
* On Linux and FreeBSD completions will always be case-sensitive as they used to be.
  There does not appear to be any API to query case sensitivity of a given path or even
  the entire file system.
  At most, we could white-list a number of case-insensitive file systems.

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