Change the grammar to express functions as two expressions combined by a ':' operator.

The initial approach was to express functions as a "term" -- like "literal".
This worked fine in principle, but resulted in very poor error messages,
because the function parser needed to allow backtracking to distinguish

  { a }: a  ==>  Fun (AttrSetP Nothing [("a",Nothing)]) (Ident "a"))

from

  { a = null; }  ==>   AttrSet False [Assign (SIdent ["a"]) (Ident "null")])

At the time the parsers encounters the opening '{' bracket, it cannot decide
whether to match a function or an attribute set, because both constructs look
the same with a single token look-ahead. Given an erroneous input like

  { a ? null }: { b = a /* semicolon missing here */ }

..., the parser fails to match a function. Then it backtracks, trying to match
an attribute set, but that fails, too. So it ends up complaining about the '?'
character, saying that this is not legal syntax for an attribute set. We would
prefer the parser to complain about the missing semicolon, though!

To accomplish this, the parser must be able to commit the parsing a function at
the point where it encounters the colon, at latest. Consequently, this commit
introduces a "term" for attribute set patterns and a general purpose colon
operator to form functions from terms:

  > parse expr "{ a ? null }: { b = a /* semicolon missing here */ }"
  Left ""{ a ? null }: { b = a /* semicolon missing here */ }"" (line 1, column 52):
  unexpected "}"
  expecting operator or ";"
  ambiguous use of a right associative operator

The downside is that the grammar now accepts illegal function forms that need
to be recognized at the time the AST is processed. For example:

  > parse expr "{ a = null; }: b"
  Right (Fun (AttrSet False [Assign (SIdent ["a"]) (Ident "null")]) (Ident "b"))

  > parse expr "http://example.org: b"
  Right (Apply (Lit "http://example.org:") (Ident "b"))