* Instead of every digit being a stack-modifying standalone
  command, there is a single continuous parser state (teco_state_number)
  now - even though it has certain unique characteristics.
  They are consequently documented in the ARITHMETICS AND
  EXPRESSIONS chapter of sciteco(7).
* A number will therefore be rubbed out entirely by CTRL+W,
  including a possible @-modifier.
* (!) Spaces within constants are no longer ignored, but will push
  separate numbers to the stack instead (`1 2 3` pushes 3 numbers).
  The significance of the `,` operator is thus further reduced.
* (!) You can no longer "append" to numbers on the stack as in
  `Qa001` - this was never actually used and caused more confusion.
* (!) Digits outside the current radix are no longer accepted.
  E.g. digit 2 after `2^R`. This feature was also never used.
* (!) Octal constants are supported with leading zeros as in C.
  This works regardless of the current radix set via `8^R` or `^O`.
  It remains to see whether this is actually useful or is rather
  annoying (since every constant beginning with 0 is automatically
  octal, you cannot left-pad arbitrary numbers with 0).
* Hexadecimal constants are supported by at-modifying them as in
  `@0ff`. They must still begin with a digit 0-9 and since A-F are
  valid SciTECO commands, you may need additional spaces to separate
  hexadecimal constants from regular commands as in `@0ff D`.
  During syntax highlighting the number style is extended back to the
  at-sign.
  Note: Hexadecimal constants couldn't have been realized via
  `16^R` (or some shortcut) since that depends on runtime state, but
  we must know during parsing whether symbols A-F are part of the
  number of regular SciTECO commands.
* The new hexadecimal constants are used in the color schemes now.
  Thanks to them, we no longer need workarounds like the "color.rgb"
  macro.
* Since numbers don't have a dedicated terminator character, but any
  letter may terminate it, the number state must behave similar to a
  start state. Consequently, hexadecimal constants will currently be
  auto-case-folded if you enabled this feature.
  I recommend not to write hex constants in upper-case, though.
  Perhaps this should be worked around with a custom process_edit_cmd()
  callback.
* Test suite updated

This was missing the undoing after the refactoring
in a53fa85dabdfc2c47ec0c9e6626ddda2379a8e38.

This was already done for the goto table, but by first looking up
whether a label already exists in the table.
Since the insert operation already reports entries with the same key
in the tree, we should rather check that. This saves one goto table
lookup per label definition, but on the other hand results in excess
allocations in case of encountering a label twice.

In teco_help_set(), we did not check for collisions at all.
Even thouch they are very unlikely, we could encounter them if
a topic is defined on exactly the same position as in
.SCITECO_TOPIC foo
.SCITECO_TOPIC foo
In this case, we leaked memory.

* This mirrors how the `FT$` command toggles through several results.
* Some non-unique .SCITECO_TOPICs have been added to sciteco(1) and sciteco(7).
* This works by inserting non-unique keys into the help topic RB tree - or rather
  by turning filename:pos also into keys since rb3ptr does not allow non-unique keys.
  When searching for a topic, we sort lower than any other entry with the same name.
  This way we can easily iterate all entries with the same name (search topic).
  The alternative would have been to maintain a linked list in each and every
  teco_help_topic_t.
* teco_rb3str_auto_complete() now filters out possible duplicate keys.
* Updated test case: check for non-unique topic names.

fixup to 5b9ac0d43650bc7a1fe5d6e134e74bda1243fd99.

That variant of the command is explicitly used to launch the LSP.
It makes no sense to return an error message in case of success.

This currently only works in insert commands after enabling the immediate
editing modifier via CTRL+G and if the LSP was already launched
(e.g. by an explicit `FT$`).
File name completions are still performed with an activated ^G modifier
only if the LSP is shut down.

Just like for file names, the modifier is automatically cancelled after
a successful completion - there is little sense in completing several
symbols in a row.

This will be important once we're doing LSP auto-completions.
Until a completion is complete, we do NOT want to disable the modifier however
since otherwise it can be disabled after a partial completion if there happened
to be a rubbed out command line.
Discarding a rubbed out command line consequently no longer disables
the modifier as well.

Any change of the modifier is now logged with an Info-level message.

Some rudimentary test case has been added for rub-in via ^G.

This is similar to `\` at the line end in many languages like C and
allows you to split a very long string argument over several lines without
adding the EOL characters themselves.
The TECO equivalent to `\` would be ^Q, but it would be a semantic exception since
^Q (escaping) is supposed to _preserve_ the value of the following character.
Therefore I decided to use ^E instead.
This works with DOS and Mac line breaks as well.