This release is mainly for the upcoming FreeBSD package.

* We cannot call it "." since that introduces a local register
  and we don't want to add an unnecessary syntactic exception.
* Allows the idiom [: ... ]: to temporarily move around.
  Also, you can now write ^E\: without having to store dot in a register first.
* In the future we might add an ^E register as well for byte offsets.
  However, there are much fewer useful applications.
* Of course, you can now also write nU: instead of nJ, Q: instead of "." and
  n%: instead of "nC.". However it's all not really useful.

* This way the search mode and radix are local to the current macro frame,
  unless the macro was invoked with :Mq.
  If colon-modified, you can reproduce the same effect by calling
  [.^X 0^X ... ].^X
* The radix register is cached in the Q-Reg table as an optimization.
  This could be done with the other "special" registers as well, but at the
  cost of larger stack frames.
* In order to allow constructs like [.^X typed with upcarets,
  the Q-Register specification syntax has been extended:
  ^c is the corresponding control code instead of the register "^".

* Usually you will only want -^X for enabling case sensitive searches
  and 0^X for case-insensitive searches (which is also the default).
* An open question is what happens if the user sets -^X and then calls
  a macro. The search mode flag should probably be stacked away along
  with the search-string. This means we'd need a ^X special Q-Reg as well,
  so you can write [^X[_ 0^X S...$ ]_]^X.
  Alternatively, the search mode flag should be a property of the
  macro frame, along with the radix.

* You can now set a per-file tab style, that differs from the defaults established
  in the ED hook.
  This is important especially since we do not yet support per-project .teco_ini
  scripts where you could establish differing policies depending on the VCS repository.
  (The latter would be easy to implement, but we cannot currently easily extend the
  existing ED hooks.)
* It's unlikely that files contain an ASCII 27, but not impossible.
  Therefore we now use ASCII 0 (^@) as a terminator.
  This indeed be safe under UNIX.
  Even better would be a string building construct for escaping ASCII 27 ($), though,
  as that would work with arbitrary bytes.

* should also fix Win32 nightly builds
* Even though we weren't using main's argv, but were using glib
  API for retrieving the command line in UTF-8, newer MinGW runtimes
  would fail when converting the Unicode command line into the system codepage
  would be lossy.
* Most people seem to compile in a "manifest" to work around this issue.
  But this requires newer Windows versions and using some Microsoft tool which isn't
  even in $PATH.
  Instead, we now link with -municode and define wmain() instead, even though we still
  ignore argv. wmain() proabably get's the command line in UTF-16 and we'd have to
  convert it anyway.
* See https://github.com/msys2/MINGW-packages/issues/22462

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