* it appears to behave similar to Mac OS with regard to recursions

* fixes test cases like 3<%a:>
* you can now use :F< in pass-through loops as well
* F> outside of loops will now exit the current macro level.
  This is analogous to what TECO-11 did.
  In interactive mode, F> is currently also equivalent to $$
  (terminates command line).

* This is not easy to fix (show errors when encountering these constructs without
  preceding if <"> statements) and would require complicating the parser only to
  detect this.
  On the other hand, keeping things as they are does not really harm anybody.

* An empty but valid teco_string_t can contain NULL pointers.
  More precisely, a state's done_cb() can be invoked with such empty strings
  in case of empty string arguments.
  Also a registers get_string() can return the NULL pointer
  for existing registers with uninitialized string parts.
* In all of these cases, the language should treat "uninitialized" strings
  exactly like empty strings.
* Not doing so, resulted in a number of vulnerabilities.
  * EN$$ crashed if "_" was uninitialized
  * The ^E@q and ^ENq string building constructs would crash for existing but
    uninitialized registers q.
  * ?$ would crash
  * ESSETILEXER$$ would crash
* This is now fixed.
  Test cases have been added.
* I cannot guarantee that I have found all such cases.
  Generally, it might be wise to change our definitions and make sure that
  every teco_string_t must have an associated heap object to be valid.
  All functions returning pointer+length pairs should consequently also never
  return NULL pointers.

* This test case no longer fails on MacOS and MinGW builds probably
  because the settings of the underlying libpcre library changed.
* Since these settings are not predictable, cannot be queried and may even change on some
  flavors of Linux, it has been completely disabled for the time being.
* Should fix CI and nightly builds on MacOS and Win32

* The C standard actually forbids this (undefined behaviour) even though
  it seems intuitive that something like `memcpy(foo, NULL, 0)` does no harm.
* It turned out, there were actual real bugs related to this.
  If memchr() was called with a variable that can be NULL,
  the compiler could assume that the variable is actually always non-NULL
  (since glibc declares memchr() with nonnull), consequently eliminating
  checks for NULL afterwards.
  The same could theoretically happen with memcpy().
  This manifested itself in the empty search crashing when building with -O3.
  Test case:
  sciteco -e '@S//'
* Consequently, the nightly builds (at least for Ubuntu) also had this bug.
* In some cases, the passed in pointers are passed down from the caller but
  should not be NULL, so I added runtime assertions to guard against it.

* Turns out we cannot assume that the test case never crashes on Mac OS,
  so we instead now skip the entire test case on Mac OS.
  It apparently crashes even on Mac OS when building with --enable-debug (-O0).
* Should fix Continous Integration for Mac OS.

* Test case: sciteco -e '[a'
  [aEX$$ in interactive mode would also crash.
* No longer use a destructor - it was executed after the Q-Reg view was
  destroyed.
* Instead, we now explicitly call teco_qreg_stack_clear() in main().
* Added a regression test case.

* instead, we now use `dd`.