Add support for easier handling of ambiguous trees

[PieterOlivier]

When a tree is ambigous, field access will fail in the interpeter with a static error (UndeclaredField) that cannot be caught:

module lang::rascal::tests::concrete::recovery::Amb

import ParseTree;
import vis::Text;
import IO;

syntax S = O? A a | A a; 

syntax A = "a";

syntax O = "o"?;

void testAmb() {
    S s = parse(#S, "a", allowAmbiguity=true);

    println(prettyTree(s));

    println("a: <s.a>");
}

Gives the output:

rascal>testAmb();
 ❖
 ├─ S = A a 
 │  └─ A = "a"
 └─ S = O?  A a
    ├─ ❖
    │  ├─ O?
    │  └─ O?
    │     └─ O = "o"?
    │        └─ "o"?
    └─ A = "a"

|std:///lang/rascal/tests/concrete/recovery/Amb.rsc|(291,1,<18,17>,<18,18>): Undeclared field: a for Tree
Advice: |https://www.rascal-mpl.org/docs/Rascal/Errors/CompileTimeErrors/UndeclaredField|

This makes it hard to work with ambiguous trees because every access needs to be checked.

We should have a generic way to catch these errors at a higher level, just like we do with errors caused by missing fields in error trees.

For the approach taken with error trees see:
http://www.rascal-mpl.org/docs/RascalAmendmentProposals/RAP16/

We should investigate which of the constructs discussed in the RAP16 are also affected when the tree is ambiguous and come up with a similar solution.

At first glance, field access in ambiguous trees should probably be handled exactly like field access in error trees "after the dot", only with a different wrapping exception to indicate the core cause is an ambiguous tree, not an error tree.

[DavyLandman]

This came from a discussion, and one of the insights was that this is not a true static error, as otherwise we would also have to change the typechecker to make every fieldderef on a parse tree a possible error. This is more of a runtime error (a bit like npe) that we want to be able to catch to handle generically.

[jurgenvinju]

Yes let's change this to a runtime error.

The interpreter's behavior should be (ambiguity or not):

• if the field was not declared anywhere in the scope of the nonterminal: static UndeclaredField
• if the field is not present on the current tree: dynamic NoSuchField

It's possible this is buggy by itself, and fixing this will fix the current bug.

For the ambiguous case we expect the exact same behavior, even if the field will never be available on an amb node. It should act just like an alternative production rule that does not have the field.

[jurgenvinju]

It's conceivable that we wrap these runtime errors in the ParseErrorRecovery wrapper as well, when caused by an ambiguity. Since most ambiguities are expected to be caused by error recovery, this will help language engineers write robust code in the presence of partially parsed input. WDYT? Another wrapper could be AmbiguousParseTree, parallel to ParseErrorRecovery.

Also an ambiguity can be seen as a kind of "super" parser recovery in general, so it does not not make sense.