Tree pattern matching

[ptal]

Extend the parser with "tree-shape" atoms. This will allow to provide pattern matching on enum type and for example, to directly work with the Rust compiler Lexer. Several notes:

• We require rules and rust functions to start with a lower case (rules' names and semantic action) to distinguish these from tree-shaped data.
• Tree-shaped data structure start with an upper case. It would also work in semantic action, as suggested in #53.
• We leave the type checking of the branches of the choice combinator (e1 / e2, T1 must equals T2) to the Rust compiler. It closes #73. Finally, we chose to check the branches.
• We allow atom identifiers to be parsed by the host-language rule. The purpose is to allow identifiers with a path such as in mod::BinOp(mod2::Plus). It closes #54.
• We require the function parsing these "full-identifiers" to return the "core identifier" such as BinOp for mod::BinOp so we can distinguish function/rules VS. tree-data.

Some references on this topic of tree-pattern matching with PEG:

• Warth, Alessandro. “Experimenting with Programming Languages,” 2009.
• Warth, Alessandro, and Ian Piumarta. “OMeta: An Object-Oriented Language for Pattern Matching.” In Proceedings of the 2007 Symposium on Dynamic Languages, 11–19. ACM, 2007.

[ptal]

Somewhat relevant to the discussion, if we use sum variant in semantic action, for example:

expr = addition > Addition
     /  substraction > Substraction

it becomes impossible to guess the type of the rule. We can extend the -> to specify any rust type and to be applied on rule (for convenience), the previous example becomes:

expr -> RustTy
        = addition > Addition
        /  substraction > Substraction

with RustTy the rust type.

[ptal]

Postponed because we will match on Rust tokens with another technique. This is still interesting for general pattern matching so I do not close this issue for now but, since we are in a typed context (which is different from OMeta), we might consider another approach later.

[ptal]

Triage: abandon this feature. We will focus on #93 instead.