Finally getting rid of this bad mistake of using IX for this.

Instead of going left and right, finding operators chars and replacing them
with nulls, we parse expressions in a more orderly manner, one chunk at a
time. I think it qualifies as "recursive descent", but I'm not sure.

This allows us to preserve the string we parse and should also make the
implementation of parens much easier.

For some reason, I've mistakenly disabled tests in test_expr without noticing
and I also broke "-123" parsing. Fixed.

This should make tests a bit more convenient to write and debug.

Moreover, begin de de-IX-ization of parseExpr. I have, in a local WIP, a
parseExpr implemented using a recursive descent algo, it passes all tests, but
it unfortunately assembles a faulty zasm. I have to find the expressions that
it doesn't parse properly.

But before I do that, I prefer to commit these significant improvements I've
been making to tests harness in parallel of this development.

It's an awkward register to use and avoiding its use allows us to strip the
resulting binary significantly. parseEXPR keeps the same signature though.

Again, same thing as in zasm.

To run a parseExpr on first pass would always return a false success
with dummy value because symbols are configured to always succeed on
first pass. This would make expressions like ".fill 0x38-$" so bad
things to labels because "0x38-$" wouldn't return the same thing on
first and second pass.

Revert to parsing literals and symbols after having scanned for
expressions and add a special case specifically for char literals (which
is why we scanned for literals and symbols first in the first place).

Previously, we would mess up literals like '-'.

They serve no purpose and make the code less flexible.