* Previous Scintilla version was 3.6.4 and Scinterm was 1.7 (with lots of custom patches).
  All of the patches are now either irrelevant or have been merged upstream.
* Since Scintilla 5 requires C++17, this increases the minimum GCC version at least
  to 5.0. We may actually require even newer versions.
* I could not upgrade the scintilla-mirror (which was imported from Mercurial),
  so the old sciteco-dev branch was renamed to sciteco-dev-pre-v2.0.0,
  master was deleted and I reimported the entire Scintilla repo using
  git-remote-hg.
  This means that scintilla-mirror now contains two entirely separate trees.
  But it is still possible to clone old SciTECO repos.
* The strategy/workflow of maintaining hotfix branches on scintilla-mirror has been changed.
  Instead of having one sciteco-dev branch that is rebased onto new Scintilla upstream
  releases and tagging SciTECO releases in scintilla-mirror (to keep the commits referenced),
  we now create a branch for every Scintilla version we are based on (eg. sciteco-rel-5-1-3).
  This branch is never rebased or deleted. Therefore, we are guaranteed to be able to
  clone arbitrary SciTECO repo commits - not only releases.
  Releases no longer have to be tagged in scintilla-mirror.
  On the downside, fixup commits may accumulate in these new branches.
  They can only be squashed once a new branch for a new Scintilla release is created
  (e.g. by cherry-picking followed by rebase).
* Scinterm does no longer have to reside in the Scintilla subdirectory,
  so we added it as a regular submodule.
  There are no more recursive submodules.
  The Scinterm build system has not been improved at all, but we use
  a trick based on VPATH to build Scinterm in scintilla/bin/.
* Scinterm is now in Git and we reference the upstream repo for the
  time being.
  We might mirror it and apply the same branching workflow as with Scintilla
  if necessary.
  The scinterm-mirror repository still exists but has not been touched.
  We will also have to rewrite its master branch as it was a non-reproducible
  Mercurial import.
* Scinterm now also comes with patches for Scintilla which we simply applied
  on our sciteco-rel-5-1-3 branch.
* Scintilla 5 outsourced its lexers into the Lexilla project.
  We added it as yet another submodule.
* All submodules have been moved into contrib/.
* The Scintilla API for setting lexers has consequently changed.
  We now have to call SCI_SETILEXER(0, CreateLexer(name)).
  As I did not want to introduce a separate command for setting lexers,
  <ES> has been extended to allow setting lexers by name with the SCI_SETILEXER
  message which effectively replaces SCI_SETLEXERLANGUAGE.
* The lexer macros (SCLEX_...) no longer serve any purpose - they weren't used
  in the SciTECO standard library anyway - and have consequently been removed
  from symbols-scilexer.c.
  The style macros from SciLexer.h (SCE_...) are theoretically still useful - even
  though they are not used by our current color schemes - and have therefore been
  retained. They can be specified as wParam in <ES>.
* <ES> no longer allows symbolic constants for lParam.
  This never made any sense since all supported symbols were always wParam.
* Scinterm supports new native cursor modes.
  They are not used for the time being and the previous CARETSTYLE_BLOCK_AFTER
  caret style is configured by default.
  It makes no sense to enable native cursor modes now since the
  command line should have a native cursor but is not yet a Scintilla view.
* The Scintilla upgrade performed much worse than before,
  so some optimizations will be necessary.

 * Usually, Scintilla will now be built with -O2
 * this can improve performance significantly over the standard Scintilla -Os
   (up to 10%).
 * this also allows link-time-optimizing both Scintilla and SciTECO
   (which are linked statically) by adding -flto to CFLAGS, CXXFLAGS and LDFLAGS.
   Link-time-optimization will both reduce the total binary size
   and improve performance slightly since scintilla_send_message() can be
   inlined.
   An -O3 optimized Scintilla when linked with LTO results in an only 300kb
   larger SciTECO binary.
 * the highest possible optimization thus requires the following maintainer
   flags on the ./configure command line:
   CFLAGS="-O3 -mtune=native -march=native -flto"
   CXXFLAGS="-O3 -mtune=native -march=native -flto"
   LDFLAGS="-flto"
 * Windows and Debian builds use link-time-optimization now.
   On Windows - where we link in everything statically - building
   the dependant libraries with -flto could improve performance
   even more.
 * Debian builds respect the default hardening flags of the build
   server now. This should ensure that SciTECO is built for the
   correct architecture at the recommended optimization level etc.

 * depend on Gtk+ 3.10. If necessary older versions should also
   be supportable. GtkOverlay was already introduced in v3.2
 * A fallback for GtkFlowBox is compiled in if the Gtk installation
   is too old. This applies even to Ubuntu 14.04 which still runs
   Gtk v3.10.
 * the threading the Gtk UI is left as it is for the time being
   even though the synchronization mechanism has been deprecated.
   Alternative approaches have to be tried out and benchmarked.
 * Completely revamped the GtkInfoPopup widget.
   It is now as powerful as the Curses UI's popup widget.
   * A GtkOverlay is used instead of the top-level window hack
     in the Gtk2 version.
   * GtkFlowBox is used to lay out the columns of the popup.
   * I had to work around restrictions of GtkScrolledWindow
     by writing my own poor-mans scrolled window which handles
     size requests correctly.
   * The popup window no longer overflows the screen size,
     instead we scroll.
   * Scrolling pagewise is finally supported. Wraps at the
     end of a list just like the Curses UI.
   * Instead of using only two stock icons, we now use
     GIO to get file and directory icons for the current theme.
     This looks even better.
   * The GtkFlowBox allows selections which can be used for mouse
     interaction later. But this is not yet implemented.
 * Theming of the popup widget and command line is still
   not performed correctly.

the CURSES_CFLAGS variable from my patches has been renamed to
CURSES_FLAGS in the upstream commits, so this was broken in
SciTECO since 3770ea2e

 * enabled via --with-interface=xcurses, so we can configure
   it automatically via xcurses-config.
   This also adds XCURSES_CFLAGS and XCURSES_LIBS.
 * The X11 window class name is set to "SciTECO".
   X11 resource overrides can currently not be set via
   sciteco's command line. The user may use .Xdefaults though.
 * interruptions via CTRL+C are currently not supported.
   Apparently, XCurses also does send SIGINT in cbreak() mode.
   An XCurses-specific hack would be cumbersome.
 * ~InterfaceCurses() should probably be rewritten.
   Curses cleanup should be completely in restore_batch() as
   the destructor may be called after Curses-cleanup handlers.
   E.g. isendwin() SEGFAULTs on XCurses when called from the
   destructor.

 * requires a recent patch to Scinterm
 * can be overwritten in SciTECO's build system via NCURSES_CFLAGS or
   PDCURSES_CFLAGS.
 * NCURSES_LIBS has also been introduced. The check for ncurses
   will now use pkg-config if available.
 * eases multiple builds with different Curses variants
   (e.g. when cross-compiling for Windows)
 * pass more toolchain variables into Scintilla build process (CC and RANLIB).
   This should fix Cross-compiling Scintilla/Gtk
 * Pass GTK cflags into Scintilla/Gtk build system.

 * Scintilla was built as a .PHONY target, so we trigger its build
   process always when we depend on scintilla.a.
   The problem was that a real file (scintilla.a) was declared .PHONY
   which meant that it was always considered updated by Make.
   This triggered a relink of everything depending on scintilla.a.
   Always. When doing a bootstrap build, this would always result
   in rebuilding the symbols-*.cpp files, etc...
 * Now the Scintilla build process will always be triggered,
   but scintilla.a is handled like an ordinary target.
   When we depend on scintilla.a our recipe will only be executed
   if the recursive make for Scintilla actually did update scintilla.a

when hacking Scintilla, it is useful to recompile it as
necessary. Since SciTECO calls the Scintilla/Scinterm Makefile
recursively, we do not know the libraries dependencies in
SciTECO's build system. It therefore makes sense to define
externally built targets as phony, so the recursive make
is called every time scintilla.a is required. If scintilla.a
is already up to date, the additional recursive make call
won't hurt.

this should simplify building SciTECO for new users

 * compiler and archiver are passed down from Autoconf,
   so cross-compiling should work transparently
 * `make clean` will also clean the Scintilla source tree
 * there is no longer any need for "source bundles" as
   tar balls also contain Scintilla/Scinterm now
 * building from Git is not much more difficult than building
   from a tar ball
 * The versions of Scintilla/Scinterm embedded as submodules
   already contain all the patches necessary (currently none are
   necessary), so there's no need to have patch files in the
   repository
 * INSTALL instructions have been rewritten
 * the --with-scintilla and --with-scinterm site-config options
   have been kept. But they should be rarely necessary now.