* This has been broken for some time, but it didn't crash in v2.5.2.
* Even when it did not crash, the search just failed.
  In TECO-11 (judging by TECOC), we must throw an error, though.
  Video TECO on the other hand always succeeds in such cases.
* Added test case

If you had a partial success during interactive searching, dot would be
left at that position since the failure handling only reset via SCI_GOTOPOS.
This is now fixed by restoring the initial dot in glyphs as well.
All existing occurrences of "dot" have been renamed to "pos" for consistency.
(Nowadays, "dot" should be reserved for glyph positions since this is what
`.` returns. Especially if both kinds of positions are used in the same code.)

A test case has been added.

This has been broken since 685507922b0b75da5935076395a5b1ec1ef58356.

It was never required as a separate callback/method,
but was kept merely for consistency.
Since we now call teco_current_doc_set_dot() in
teco_qreg_dot_set_integer(), we'd have to split it up into
an "undo" method as well. I decided to get rid of the
superfluous Q-Reg method instead.

It's quite likely we could get rid of the remaining
undo_set_string(), undo_exchange_string() and undo_edit()
callbacks as well (TODO).

Previously almost all glyph-to-byte offset conversions consulted
Scintilla's line index and counted characters on the resulting line.
For instance a simple expression like `.+1J` would scan the same line
twice completely, which would be very slow on pathologically long lines.
Even insertions did that due to having to update the ^Y ranges.
If you repeat such an operation over all characters as in `<.+1:J;>`
you would have complexity O(n^2) for n = line length.
Only commands with an explicit relative nature like `C` and `A` would
use teco_view_glyph2bytes_relative() which scans beginning at dot
as long as the relative movement is less than 1024 glyphs.

Wit the new heuristics almost all glyph-to-byte and byte-to-glyph
conversions can make use of that optimization.
This requires that dot must at all times be known in glyphs as well -
the byte position is managed by Scintilla (SCI_GETCURRENTPOS).
We therefore introduced teco_current_doc_set_dot() and
teco_current_doc_get_dot() to update dot in the current buffer or
Q-Register -- it cannot be stored along with the view since
Q-Registers share a single view.
A number of auxiliary functions have been introduced for
converting relative to a known (glyphs,bytes) offset pair
and for converting absolute and relative positions with regard
to the current doc and SCI_GETCURRENTPOS position.
Of course this is error-prone since the glyph and dot positions
are interdependant - they must always be kept in sync.

With these new optimizations even pathologically long lines can
(usually) be managed even in UTF-8 documents.
It does not address slow-downs in Scintilla's line layout, yet.
grosciteco.tes for instance runs twice as fast now.

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