* terex disables assertions by default unless you add `-DREG_DEBUG`.
  Since we heavily modified the original by Henry Spencer it makes sense
  to enable assertions.
* dlmalloc will still be built without assertions even if --enable-debug
  is given since that has a significant speed impact and I consider
  dlmalloc to be rock solid. It would need `-DDEBUG=1` to enable assertions
  (among other things).
  We only disable additional checks in dlmalloc if --disable-debug.

* GSpawn ends up calling posix_spawnp() which passes down a small
  4kb stack to the child process until it exec()s.
  This stack could be overflowed easily on code paths where the
  path is not already absolute and when many shared libraries
  are involved.
* The crashes could therefore only be observed on Gtk builds and
  in UNIX shell emulation mode (0,128ED). Sample test case:
  gsciteco -e '0,128ED @EC"ls"'
  Theoretically a relative $SHELL variable could have also triggered
  it.
* I assume that the bug will be fixed in libc at least by the time of
  FreeBSD 16.
* As a workaround we resolve relative program paths before passing
  them to g_spawn_async_with_pipes().

* The previous checks for interruptions only helped in a few corner cases
  like for very high search-repeat counts or during backwards searches across
  the entire buffer.
* But even with terex' more predictable runtime properties
  a single regex execution can hang quite a long time.
  E.g. `S^EM^X$` on a huge buffer or even more so with backreferences as in
  `S^~(.*)\1$`.
* We now use the new tere_set_is_interrupted_cb() to register
  teco_interface_is_interrupted(). Types should be compatible as long
  as gboolean resolves to int.
* It's no longer necessary to manually check for teco_interface_is_interrupted()
  since tere_exec() now returns REG_EINTR in case the callback returned TRUE
  in which case it's handled by teco_error_regex_set().

It for some strange reason had to be escaped for AREs
even though a single freestanding `)` cannot mean anything.

* Allows searching by regular expressions.
  We will never support all ARE constructs in TECO patterns, so this is useful to have available.
* Can only be typed upcaret.
  This leaves ^E~q available as an escape-regexp string building construct.
* Once we replace the pattern2regexp converter with a custom terex lexer,
  we might want to restrict ^~ to the beginning of the pattern.
  Currently, however it can be anywhere, so you can mix TECO patterns with regular expressions.

The calculation of the block start was faulty and could cause underflows
resulting in unpredictable behavior.

This was using g_regex_escape_string() which always translates a null byte
to `\0`, which is ambiguous if followed by other digits, so a null byte followed
by a digit would result in a wrong regular expression.
Actually the same could happen outside of character classes, ie. `@S/^@1/` was also broken.
Also it does not escape `-`, so the result cannot be used in character classes.
This is fixed now in a new custom implementation teco_regex_escape().
Once moving to a custom terex lexer, we won't need any of this of course
unless we want to provide a regex escaping string building construct.

We are now completely free of GRegex.

It's now a private struct, so we can include the regex_t wihout
having to draw in the terex headers everywhere.

* terex is based on Henry Spencer's regular expression engine for Tcl.
  It is a hybrid NFA/DFA design which has better worst-time runtimes than
  the backtracking PCRE. Memory usage is also limited and can no longer
  increase catastrophically.
* It should no longer be possible to crash SciTECO with pathological
  searches.
* Since it reliably supports partial matches (REG_EXPECT) we can
  now enable the new backwards-search algorithm by default.
  This used to be broken because of a glib bug, which I already
  fixed. It would however take a long time until this ends up
  on the majority of glib installations.
* Regexp executions can still be quite slow if you are looking
  for a pattern at the end of a huge file, which can hang the editor,
  but this can now at least theoretically be solved by adding
  hooks into terex to poll for interruptions.
* We can now also get rid of a TECO-pattern to regexp translation
  step by directly generating terex tokens (TODO).
* Performance-wise terex appears to be slower than PCRE for simple
  forward searches even when linking everything with optimzations (FIXME).
* Having a stand-alone regular expression engine is also a huge
  step in getting rid of glib.

See also: https://git.fmsbw.de/terex/about/