Added basic support for parse errors

Parse errors list the name of tokens or rules that were expected at the
point where they occurred. They also describe the state the parser was
in when it happened (for instance, if the error happened within a
local-statement, a method definition, or a record literal).

To achieve this, the grammar needs to be annotated with label(X Parser)
and context(X Parser).

This does have a very negative effect on parsing performance.
Parsing rules are now looked up at translate-time

The main purpose of this patch is to improve performance of the
parser. It does so significantly (and is in fact almost enough to make
the parser as fast as it was when it didn't handle errors).

Every time the parser encountered a non-terminal rule, it would look up
the procedure that needed to be called. Since this happens extremely
often, moving the code that does this to the time when the rules are
being translated (which only happens once) is very helpful.

Notice that this works even for mutually recursive rules when none of
them are yet defined thanks to unbound variables.

PEG.oz also allowed for each context to specify which grammar to
use. Since none of the current parsers used that feature, it has been
removed in the interest of simplicity and performance both (it could be
re-added with close to cost when it isn't being used with an option if
need be).
Disable caching for certain rules

The UseCache option the parser currently provides is an all-or-nothing
deal. However, Parser.oz is unacceptably slow when it is set to false
but very memory hungry when it is set to true.

This patch aims at providing a finer-grained control over this by
explicitly specifying some rules that do not benefit enough from caching
for it to be worth it. This usually increases parse time but reduces
memory usage.

The parser seems to perform acceptably without caching for the rules for
which it has been disabled, however more experimenting can still be done
to find for which rules the time gain isn't worth the memory expense.

(As a sidenote, I do not understand why caching pB is faster: that rule
is ran extremely often, but how can directly running it, seeing how
trivial it is, be slower than checking if it's in the cache and branching?)