* Requiring state callbacks by generating their names (e.g. NAME##_input) has several disadvantages:
  * The callback is not explicitly referenced when the state is defined.
    So an unintroduced reader will see some static function, which is nowhere referenced and still
    doesn't cause "unused" warnings.
  * You cannot choose the name of function that implements the callback freely.
  * In "substates" you need to generate a callback function if you want to provide a default.
    You also need to provide dummy wrapper functions whenever you want to reuse some existing
    function as the implementation.
* Instead, we are now using static assertions to check whether certain callbacks have been
  implemented.
  Unfortunately, this does not work on all compilers. In particular GCC won't consider
  references to state objects fully constant (even though they are) and does not allow
  them in _Static_assert (G_STATIC_ASSERT). This could only be made to work in newer GCC
  with -std=c2x or -std=gnu23 in combination with constexpr.
  It does work on Clang, though.
  So I introduced TECO_ASSERT_SAFE() which also passes if the expression is *not* constant.
  These static assertions are not crucial - they do not check anything that can differ between
  systems. So we can always rely on the checks performed by FreeBSD CI for instance.
  Also, you will of course quickly notice missing callbacks at runtime - with and without
  additional runtime assertions.
* All mandatory callbacks must still be explicitly initialized in the TECO_DEFINE_STATE calls.
* After getting rid of generated callback implementations, the TECO_DEFINE_STATE macros
  can finally be qualified with `static`.
* The TECO_DECLARE_STATE() macro has been removed. It no longer abstracts anything
  and cannot be used to declare static teco_state_t anyway.
  Also TECO_DEFINE_UNDO_CALL() also doesn't have a DECLARE counterpart.

We cannot rely on the central teco_cmdline_update() call per keypress
in this case.
The analogous call was removed in 4e6ddd6c329d56055a732c6344df019f0d997aaf,
so this was a recent regression.

* This allows for several customizations.
  * You can simply increase the visible command line history.
    For that you must also set SCI_SETWRAPMODE(SC_WRAP_CHAR).
    An example was added to fallback.teco_ini.
  * You could also set SCI_SETLINEENDTYPESALLOWED(SC_LINE_END_TYPE_DEFAULT)
    to see the structure of inserted text.
* Alternatively we could have introduced a new command like EP or FW
  and also overload it to replace the current ED&2048 (e.g. -EP and EP).
  In DEC TECO `W` comes closest to what 5EJ now does.

* Instead of rendering a teco_string_t into a Scintilla view (GTK)
  and an ncurses window (Curses), it is now a Scintilla view and document
  that is modified directly.
* Reduces redundancies between GTK and Curses UIs.
* It will be more efficient on very large command lines, especially on GTK.
* We can now redirect Scintilla messages to the command line view in order
  to configure syntax highlighting, the margin, rubout indicator style and
  scroll behavior (TODO).
* This will also simplify the configuration of multi-line command lines (TODO).
* Since INDIC_PLAIN is not supported by Scinterm, rubbed out command lines
  are now styled with INDIC_STRAIGHTBOX (background color).

* `0,2ED` is roughly equivalent to `-EX`
* `ED&2` can be used to query whether EX has been run.
  This is useful if macros can run EX.
* `2,0ED` could be used to cancel the effect of EX.
* But the real motivation is for implementing a REPL script.

In particular, fixes the test case `3<255=>` which would print
only one number in interactive mode.

Small slow downs will not be noticable for interactively executed commands,
so we can well discriminate (G_UNLIKELY) against such code paths.

* These are famously in DEC TECO-11, but also in Video TECO.
* The implementation is tricky. They need to use lookahead states,
  but this would be inacceptable during interactive execution.
  Therefore only if executing from the end of the command line
  `==` and `===` are allowed to print multiple values.
  The number is therefore also not popped form the stack immediately
  but only peeked. It's popped only when it has been decided that
  the command has ended.
* This may break existing macros that use multiple `=` in a row
  to print multiple values from the stack.
  You will now e.g. have to insert whitespace to separate such `=` commands.