Some platforms could require an explicit `-lm` for functions from the
math library, while others export these symbols in libc.

This was failing on aarch64 and ppc64 (via OBS) because they are
rounding to another approximation than amd64.

* We are now buffering until the end of the number constant before converting
  it to an integer or float.
* This way, the integer part of a floating point number does not necessarily
  have to fit into an teco_int_t -- floats can approximate very large numbers.
  When detecting a floating point number, we're parsing into floats from the
  very beginning.
  The behavior has been compared with Lua 5.4 and a test case has been added.
* Also, integers constants are now checked for overflows.
  Otherwise, constants could be arbitrarily long and the result would
  be unpredictable.
  Operations on integers are still not checked for overflows, though, since
  you might want to rely on it, e.g. for overlapping integers. But that
  might actually be pretty useless, especially with signed integers, so we
  might want to change that in the future.
* Having both overflow checks and increased floating point constant range
  is the reason we cannot practically immediately parse into a number,
  not even if we kept both an integer and float accumulator at the same time.
* Also fixes a memory corruption issue that existed since
  4aa2b717f9e050783b567540d9bb0193d692e3e9.
  You must emit undo tokens for fields in state machines only if
  ctx->parent.must_undo, i.e. if the state machine is not temporary as
  during a macro call.
  A test case has been added.

We don't have g_size_checked_add(), but these are just wrappers
around the GCC/Clang intrinsics anyway.

This includes teco_state_number, `\`, all operators, braces, comma,
`^_`, `^O`, `^D`, `^R`.

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

This was missing the undoing after the refactoring
in a53fa85dabdfc2c47ec0c9e6626ddda2379a8e38.