Completely overall parser

Along with a decent amount of parser reorganization, this commit
includes three major changes:
1. Short circuit operators are implemented as keywords
2. Operators are now looked up at runtime
3. Now uses a context sensitive lexer

Originally I was planning on using `||` and `&&` as the short circuit
operators in V. This fits with its roughly javascript/C like syntax.
However, from the ideology of Ruby, it is far too difficult to allow
overloading of the short circuit operators without a form of lazy
evaluation. Using keywords `or` and `and` for these operators removes
the weird special case operators of `||` and `&&` and simplifies a bit
of the parser do to the removal of all special operators except `.`.
This does not use the precedence used in Ruby, but only act as simple
operators and even supports precedence change by whitespace like the
other operators.

On another note, actual operators are now looked up only at runtime.
For example `2 + 2` is equivalent to `ops['+'](2,2)`. This for a very
simple operator overloading scheme where you can simply assign to the
ops table which gets used at runtime. Having an ops table seperate from
the scope keeps things bit more organized and reduces table collisions.
Originally, operators were not implemented this way, because I did not
think it was possible to cleanly seperate knowledge of operators from
parse time without losing common functionality. For instance `a <= b`
is ambigous and may be parsed as `a = a<b` and `a == b` could be
parsed as `a = =b`.

This ambiguity in parsing operators was fixed by making the lexer
context sensitive. The lexer has been for small cases such as how it handles
new lines in parenthesis by uses flags set by the parser, and this has
now been extended to specifying if the parser is in a statement. This
single bit of information is enough to resolve the ambiguity with
operator assignments. For example `a <= (if (b <= c) b else c)` is
cleanly parsed as `a = a < (if (b <= c) b else c)` because the first <=
is found in a statement while the second in only an expressions.
`(a <= b)` is parsed as `(a <= b)` because parenthesis force the parser
to interpret it as an expression.

The downside of a context sensitive lexer, is that the lexer is context
sensitive, and requires synchronization with the parser. This prevents
any form of lookahead for differentiating between expressions such as
`[fn() hi]`, `[fn hi() hi]`, `[fn: 'hi']` all of which should result
in different constructs. Originally the parser handled these with enough
states, but rather than letting the complexity grow, this hackily fixed
by adding only a single character of lookahead in the lexer. When
parsing keywords or operators, the lexer consumes the trailing
whitespace. The lexer can then use the next character to resolve
ambiguities. This does require constructs such as `[fn :: 'hi']` being
parsed as `[fn: (:'hi')]`, but because of the special handling of
assignments that is already present, I don't think this will be an issue.
Parenthesis can always be used to force expression parsing.