Refactor stmt to ease bugfix: reduce duplication

Use the optionMaybe combinator. This reduces code duplication and
left-factorizes the grammar somewhat, potentially improving error
messages. Consider parsing:

foo : * = Pi T . T;

This statement is incorrect, because the grammar requires Pi terms to
have a type annotation, as in `Pi T : * . T`. However, due to
backtracking, we get the wrong error here.

With this fix, when parsing:

foo : * = Pi T . T;

we will no more not try parsing this as `ident args '=' expr` and get a complaint about ": *" (see issue #9).

However, this grammar still requires backtracking, since expressions
can well start with identifiers. So, on the example above, we'll
backtrack and try to parse it as `expr`, and we'll still complain
about the ':'.

Using left-factoring for that seems like a nightmare, subsequent
commits will have a different solution.
Refactor stmt to allow bugfix: push down semicolon

See next commit for a rationale.
Fix #9: Try expressions first, backtrack to definitions

To get the right backtracking behavior (in our case), we need to try
parsing a statement as a definition only after all other alternatives,
that is, after checking if it's a valid expression. This way, if
parsing as a definition fails, we don't backtrack to anything
else.

This might make error messages worse for expressions, but unless
a better fix can be found that's a reasonable tradeoff, because
definitions are often more complex than expressions. As a workaround,
turning `expr;` into `freshName = expr; freshName;` will improve the
error message on `expr`.

However, this would not work without the previous commit: the
beginning of every definition is a syntactically valid expression, so
`try expr` never fails. However, `expr` will not parse the whole
definition; to turn this into a failure, the simplest approach is to
push the parser for the semicolon inside the alternative productions
for statements and inside the try, as done in the previous commit.

Conceptually, pushing a semicolon into the branches should not make a
difference, but that's only valid for CFGs. Even LL(inf) parsers would
have the same problem - (a ';' | b ';') and (a | b) ';' have different
behaviors.

The need for such a transformation points to a modularity problem in
Parsec: you can't give them a compositional semantics mapping them to
CFGs. But the only way to achieve that in general would be using
generalized parsing.
Merge pull request #11 from Blaisorblade/issue/9

Fix #9: try expressions first, backtrack to definitions