Parser: Completely rewrite expression handling (and why). (long)

The old thinking for expressions was that an expression was in one of two
states: "Need value" and "Need binary op". For a long time, and for the most
part, this worked nicely...on the outside. On the inside, it was two LARGE and
growing functions that had lots of continue/break statements. Trying to figure
out what something was doing was a joke.

Some new syntax was also introduced recently. Consider a static call, an
access to some member of a class using the class name. It goes like this:
    ValueError::new

This is a function. It can be called OR it may be used as a value. The two
function model of expressions was not good at handling this.

It should also be possible to access members of a class which may or may not
be callable. The syntax should look like this:
    ValueError v = ValueError::new("Test").message

In this case, message is a string attribute of the ValueError class. It is not
callable. However, there may be callable members of classes later. The two
function model wasn't good at handling this...which is part of why the
exceptions branch did not include it. The problem was "do I check for a left
parenth? If a parenth, caller must continue to value handling, otherwise break
to binary." But...what about . accesses and subscripts?

What if I want to do this?
    MyClass f = MyClass::new("abc", 123).funclist[0](1)()

I don't think the parser could handle it. Nor could it handle this:
    any a = "abc".concat

=====

Enter the new expression handler. Expressions are now done as a single
function with helpers. It has three important states: I demand a value, I
might need a value, and I want an operator. An operator can be a subscript,
left parenth to call, a binary op, comma, etc. The functions that it calls to
handle things also get an address of the state, so they can easily fix state
information. This has also allowed bad token handling to be condensed into one
area instead of scattering a bunch of unexpected token stuff all through the
expression loop.

Perhaps the best part of the new expression engine is that each pass occurs in
a single function, so an fprintf trap becomes extremely useful. Also, I do not
think that the above issues will still haunt the new expression thingy.

Finally, I had to patch emitter's eval_call to not eval tree_readonly. This
has to be done temporarily because actually evaluating it replaces the result
where it holds the var, which corrupts any error information.

Short version: The new expression function is magic and awesome.