* Practically all calls to teco_expressions_args() must be preceded by teco_expressions_eval().
* In code paths where we know that teco_expressions_args() > 0, it is safe
  to call teco_expressions_pop_num(0) instead of teco_expressions_pop_num_calc().
  This is both easier and faster.
* teco_expressions_pop_num_calc() is for simple applications where you just want to get
  a command argument with default (implied) values.
  Since it includes teco_expressions_eval(), we can avoid superfluous calls.
* -EC...$ turned out to be broken and is fixed now.
  A test case has been added.

* 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.

* In other words, fixed `-9223372036854775808\` on --with-teco-integer=64
  (which is the default).
* The reason is that ABS(G_MININT64) == G_MININT64 since -G_MININT64 == G_MININT64.
  It is therefore important not to call ABS() on arbitrary teco_int_t's.

* Using teco_expressions_eval() is wrong since it does not pay attention to precedences.
  If you have multiple higher precedence operators in a row, as in 2+3*4*5,
  the lower precedence operators would be resolved prematurely.
* Instead we now call teco_expressions_calc() repeatedly but only for lower precedence
  operators on the stack top.
  This makes sure that as much of the expression as possible is evaluated at any given moment.

* This is not safe since the size of the stack object comes from the "outside" world,
  so stack overflows can theoretically be provoked by macros.

* It was possible to provoke operator right-associativity when placing a high-precedence
  operator between two low-precedence operators.
  1-6*5-1 evaluated to -28 instead of the expected -30.
* The reason is that SciTECO relies on operators to be resolved from left-to-right as soon as possible.
  The higher precedence operator prevents that and pushing the 2nd "-" only evaluated 6*5.
  At the end 1-30-1 would be left on the stack.
  teco_expressions_eval() however evaluates from right-to-left which is wrong in this case.
* Instead, we now do a full eval on every operator with a lower precedence, making sure that 1-30 is
  evaluated first.

* This way the search mode and radix are local to the current macro frame,
  unless the macro was invoked with :Mq.
  If colon-modified, you can reproduce the same effect by calling
  [.^X 0^X ... ].^X
* The radix register is cached in the Q-Reg table as an optimization.
  This could be done with the other "special" registers as well, but at the
  cost of larger stack frames.
* In order to allow constructs like [.^X typed with upcarets,
  the Q-Register specification syntax has been extended:
  ^c is the corresponding control code instead of the register "^".