Dyno: Type constructors for inheriting generic classes

[benharsh]

This PR implements type constructors for inheriting generic classes, which requires some substantial changes to the way type constructors are implemented in dyno.

Prior to this PR, we used a compiler-generated signature that re-used the uAST and IDs for fields in place of real formals. This breaks down when inheriting classes are involved because the parent fields will have different symbol paths from the child's fields, which can confuse the rest of dyno's infrastructure. This especially causes issues for the way we store resolution results, which cannot account for IDs from different symbol paths.

This PR addresses this problem by generating dedicated uAST for the type constructor, rather than trying to fake formals with the uAST of fields. Generating uAST on the fly like this is new for dyno, and has required some additional infrastructure. The notable changes are as follows:

• Ability to copy uAST
• Adds ID::FabricatedKind::Generated to indicate non-specific compiler-generated IDs
• Storing/fetching a BuilderResult for compiler-generated uAST based on a symbol path of a compiler-generated module
• Updating "id to ast" code to handle compiler-generated IDs

With these capabilities in place, typeConstructorInitialQuery now builds a small module to store a uAST Function that serves as the type constructor for a given type. This module pretends to be an included module living under the module in which the type was declared. For example, if a type 'R' was defined in module 'foo', the generated module would have the symbol path of foo.chpl__internal_foo_R.

This module also includes a 'use' statement for the original module, which is necessary in the event that fields' type/init expressions refer to other symbols.

Once finished building the uAST, we store the BuilderResult based on the module path.

This PR updates the implementation of IDs to treat postOrderId values less than -2 as compiler-generated IDs, but returning said IDs as a positive 0-based value so as not to confuse the rest of resolution. Internally, a value of -3 represents a compiler-generated symbol, and anything less than -3 is a child of a compiler-generated symbol, and will have its value translated into the proper positive value upon a call to ID::postOrderId(). This change was made to more easily support id-to-ast lookups in which we want to quickly determine whether an ID has an actual file behind it, or if it requires special handling because it was compiler-generated.

Other changes:

• Updated CompositeType::stringify to print generic parent substitutions
• A new resolution query findFieldIDByName is added to support these changes

Testing:

• test-dyno

[benharsh]

A potential alternative approach would be to generate this uAST at parse-time when we encounter a record or class, and instead treat it as some kind of "hidden" uAST associated with a specific file.

[DanilaFe]

Not all the way through just yet, but had some comments in the meantime

[DanilaFe]

This seems like a lot of work (for deeply nested IDs, it will keep trying to check the query database for more results, even if the ID is not compiler generated). Don't you already know if the ID is compiler-generated from its postorder ID being negative? It seems like you can skip this entire path if it isn't negative.

Also, can compiler-generated modules like this be nested? Not currently, right? In that case, you may be able to do this way more efficiently by finding the outermost symbol and trying with it directly. I suspect you can use logic in parentSymbolPath as inspiration to do so; perhaps finding the first '.' (if any) and using that?