It causes build failures on OBS for several Linux distributions.
It generally works on Linux, so it's probably related to Xvfb.

Hopefully fixes the OBS build errors.

This is useful to launch from a terminal without "blocking" this terminal.
There are tools like nohup and daemonize (BSD) to do the same, but having it
builtin is shorter to write.

It was returning the range of the search, but not of the inserted text.
Since the searched text is deleted, the range of the insertion is more useful.
It's also what was documented and what DEC TECO does.

This reverts commit 092f7d9919d9572219b7bf516933c37180e6f400.

Turns out that the "Memory limiting" test cases won't even successfully run on my PC under Valgrind.

* When typing nEBfilename$ (n != 0) you would find out that the construct is invalid
  only after typing out the entire command.
  We now throw an error immediately, ie. only Escape or string termination will be expected
  in interactive mode.
* In batch mode, nothing should have changed.

* This can be used for bootstrapping Windows binaries cross-compiled on FreeBSD or Linux
  without requiring a native build to be installed first.
  It will also allow running the test suite under Wine.
  While Linux allows registering Wine as the launcher via binfmt_misc,
  on FreeBSD we have no choice than to use --with-launcher.
* Unfortunately, SciTECO cannot currently be properly built with versions running under Wine
  and the test suite also fails.

These testcases can still be run with --valgrind on my PC.

Should fix the freebsd14-sciteco CI job.
On the other hand, these test cases do run through on my workstation,
so we might want to disable them *only* when running via CI.

* this is a SciTECO extension - it's not in TECO-11
* Allows for select-case-like constructs with default-clauses as in
  :Os.^EQa$
    !* default *!
  !s.foo!
    !* ... *!
  !s.bar!
    !* ... *!
* Consistent with nOlabel0,label1,...$ if <n> is out of range.
  Unfortunately this form of computed goto is not applicable when
  "selecting" by strings or non-consecutive integers.
* In order to continue after the <:O> statement, we must keep the
  program counter along with the label we were looking for.
  At the end of the macro, the PC is restored instead of throwing
  an error.
* Since that would be very inefficient in loops - where potentially
  all iterations would result in rescanning till the end of the
  macro - we now store a completed-flag in the goto table.
  If it is set while trying to :O to an unknown label, we can
  just continue execution.