* pkg-config check for `ncurses` fails if it failed previously for `ncursesw`.
  This is the case e.g. for ncurses from NetBSD's pkgsrc.
* No longer assume that any libncurses is not enhanced (X/Open compatible).
* SciTECO and Scinterm require to find a curses.h in the include paths.
  The ncurses check must therefore not be limited to the first best
  ncurses/ncurses.h and the like.
* We now always check for X/Open compatibility and always require
  a curses.h in the standard directories or as given by pkg-config.
* AX_WITH_CURSES was radically rewritten and is now called AX_WITH_NCURSES.
* --with-interface=netbsd-curses gets its own detection code.
  It always requires a curses.h in the standard paths and a libcurses.
  It should now be fixed for real NetBSD installations if the ncurses
  port is installed as well.
* Unified all of the curses-arguments to CURSES_CFLAGS and CURSES_LIBS.
  There is no reason we need PDCURSES_CFLAGS, XCURSES_CFLAGS etc.

Also use binary packages when testing with Poudriere
(gmake -f ./distribute.mk poudriere).

* `--enable-html-manual` renamed to `--enable-html-docs`.
* It's also uploaded to the website and linked to in README.

* After installation, SciTECO will therefore start into a more userfriendly mode
  even if the user does not create a custom ~/.teco_ini.
  It is hoped that this will scare away less of new users, who
  are not willing to read through all of the documentation.
  Still, users are warned in the absence of ~/.teco_ini.
  This warning however, might not be immediately visible, especially
  not when running gsciteco without an attached console.
  (This will change once I redo the UI and allow a number of messages
  to be queued in the message area.)
* Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini,
  but that would require installing it into $SCITECOPATH.
* Since the fallback profile will now be munged automatically
  on a wide range of systems, we set up xclip only when detecting X11
  ($DISPLAY is non-empty).
  E.g. when running under Wayland or the Linux console, you still won't
  get the clipboard registers, which is probably better than having the
  clipboard operations fail once you try to use them.
* xclip is now "suggested" on Debian/Ubuntu.
  Unfortunately we cannot pull it in only in the presence of X11.

* This does not build the current source tree.
  You must still have a properly set up ports tree somewhere.

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

* mingw-bundledlls finds and copies transitive DLL dependencies.
* Like all external one-file sources, mingw-bundledlls has been copied into contrib/
  instead of adding a submodule.
  It's taken from here: https://github.com/mpreisler/mingw-bundledlls
* Packaging is more robust now if dependant DLLs are upgraded or if we
  decide to link in more statically.
  With the old scheme, we might also miss some DLL and break builds
  without even noticing it.

* follow the current terminology:
  * PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well.
    The Win32 GUI port is now called PDCurses/WinGUI.
  * PDCurses/Win32 is now called PDCurses/WinCon.
* Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only
  to detect PDCursesMod API extensions.
  GUIs (detached from system console) might be available both in classic PDCurses as well
  as in PDCursesMod.
  Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version().
  We therefore introduced a --with-interface=pdcurses-gui that must be given whenever
  compiling for any kind of GUI port (including SDL on "classic" PDCurses).
* The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions.
* __PDCURSES__ is used to detect PDCurses whenever API extensions are not required.
* Assume that A_UNDERLINE now works even on WinCon.

 * makes sense since it already extracted information from ./configure
   that is usually substituted.
 * it already had to be run from a configured build directory
 * it required the source tree directory, which had to be overwritten
   on the Make command line when using an out-of-source build dir.
   This is no longer necessary.
 * It is still a stand-alone Makefile to keep it isolated from the main
   build system, although it could certainly be translated to Automake.
 * the generated file will now be called distribute.mk to signify
   that it is a Makefile.