After setting a non-decimal radix (e.g. 16^R), all of the fnkeys.tes
command-line editing macros would be broken.
Sometimes this can happen by accident.
It would be very tricky to write these macros in a way that works with any
currently configured radix.
So instead we now insert all of the ^T macros via :M, preserving the original radix.
As the first thing we call :M#^T^R, which checks the radix against 10 and throws
an error (currently division by zero, but this will be changed once we have
proper error handling constructs).

* Extends the SciTECO type system. A number on the expression stack
  or in a Q-register can be either an integer or a float.
* Floating point constants begin with a digit (like all other
  numbers), are followed by a `.` and an optional fractional part.
  Exponents cannot currently be written.
  E.g. `1.` == `1.0`. But `.0` would still be `.,0`.
  (!) To push an integer followed by dot, you must now write e.g. `1,.` or `1 .`.
* All of the basic arithmetic operators operate like this:
  If both operands are integers, the result is also an integer (integer arithmetics).
  If at least one of the operands is a float, the result is also a float (float arithmetics).
* All of the binary operators (AND, OR, XOR) always cast all
  operands to integer and the result is always an integer as well.
* You can "cast" integers to float by `*1.` or `/1.`.
  You can "cast" floats to integers using `#0`.
* Most commands still accept only integers. Floats are implicitly casted to integers.
  Float-aware commands are: =, \, ^W, Qq, Uq, %q and the conditionals.
* `%q` will not change the current type of register q.
* Numeric part of "lexer.font" is now a float (in points).
* You cannot currently print octal and hexadecimal floats.
  `==` and `===` are identical to `=` on floats.
* `===` is now printing hex integers in lower case.
  This is because SciTECO's coding style for hex constants is also lower case.
* `--with-teco-integer` renamed to `--with-teco-number`.

* 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

If you have projects in different languages you can set different LSPs.
The default will still come from ~/.teco_ini if you decide to set one.
The default for $SCITECO_LSP_ROOT is set by session.tes' VCS integration
based on the VCS root, but you could still overwrite it per session.

* The main interface is the `FT` command.
  `FT` was an undocumented Video TECO command for etags/ctags lookups.
  I don't want to exactly copy its interface, though.
* `FT` allows looking up symbol names,
  definitions and references.
* ctags will be supported via ctags-lsp.
  LSP support is more powerful though and works without
  regenerating TAGS files all the time.
  The LSP will also allow you to customize auto-completions
  using SciTECO itself (i.e. by writing a language server
  in SciTECO).
* For multiple results, `FT$` can be used to cycle through
  results - this should mimic repeated `S$` or `N$`.
* `:FT...$` does a fuzzy search. IMHO it's not important
  to return a status integer instead. `FT` will only
  really be used in interactive mode.
* Document synchronization is supported via hooks from
  ring.c and via Scintilla notifications.
* Currently, the LSP communication is based on blocking
  GIOChannels. This means that a misbehaving hanging
  server could "lock up" the entire editor (FIXME).
  Only on ncurses you can always kill the subprocess by
  pressing CTRL+C.
  We need helper functions in spawn.c to read and write
  with interruptions.
* The textDocument/didChange notification transmits
  not only all edits, but all files' contents as well
  during initial synchronization.
  Therefore it is optimized to write and JSON-escape
  data without copying them around in memory and without
  destroying the buffer gap.
* Use $SCITECO_LSP to configure the language server.
  You can also use `tee` to capture stdin and stdout.
  Perhaps $SCITECO_LSP should be saved in .teco_session,
  so you can change it between projects?
* $SCITECO_LSP_ROOT is used to point to the project's
  root directory. session.tes will set it up automatically.

* Always use ^ENq instead of ^EQq in the first argument of `EN`.
* Added a "Globbing" test case - globbing was undertested anyway.

* The terminal's default foreground and background colors
  are now used by default (`sciteco --no-profile`), so SciTECO
  integrates naturally into all terminal color schemes, even
  dark-on-bright ones.
* The default Scintilla colors use only 0x000000 (COLOR_BLACK) and 0xC0C0C0 (COLOR_WHITE)
  now.
* You can use `7EJ` to configure the default colors in color
  schemes or your profile.
  All existing color schemes had to disable default colors
  (`-1,-1,7EJ`) since they wouldn't look well otherwise.
* You may add `-1,7EJ` to ~/.teco_ini when using a terminal emulator
  with a washed-out palettized COLOR_BLACK.
  We cannot detect the terminal's default colors automatically.
* Scinterm updated to v6.0.
  We require a not-yet-upstreamed patch:
  https://github.com/orbitalquark/scinterm/pull/40
* In fact, we might decide not to support default colors at all in Scinterm,
  so this feature should be considered experimental.

This has been broken since v2.5.2.

* Instead of supporting only 16 predefined RGB placeholder
  values in Scintilla messages and styles, you can now use
  arbitrary RGB values and colors are allocated via the terminal
  on the fly.
  You no longer need to call 3EJ to change the default color
  palette.
* The placeholder RGB values are still available.
  Since you will usually want exact RGB values when using
  anything outside of the range of 16 default colors
  and the RGB placeholders will not always exactly correspond
  to their RGB value, you can now call `0,3EJ` to ignore
  the default palette and allocate all colors dynamically.
* Allows for more than 16 colors on the screen simultaneously.
  Also simplifies the solarized.tes color scheme.
  Since both Scinterm and SciTECO try not to touch the 16
  default colors, you also no longer have to deal with
  restoring the palette after program termination
  (which was never reliable anyway).
* Color schemes with non-default colors (solarized.tes)
  may now be broken on TERM=linux-16color (Linux VT)
  since Scinterm will get only 8 colors, but solarized.tes
  needs 16.