Improve container types calculation

[pluralia]

An AstNode instance has an optional field $container, which presents its container -- a parental AstNode. The feature makes casting an AstNode to its container pretty comfortable, however it works nicely exclusively, when there is the only one possible container for the AstNode. Current questions:

• How the case of multiple container types will be used?
• How to improve multiple container types calculation?

The problem of multiple container types calculation There are types A, B and C, and C extends A and B. If now we add a type D, containing a field with a type A, A will get a container D. Also we add a type E, containing a field with a type B, and B gets a container E. These manipulations make C invalid -- what is the C's container type?

The current solution Share container types of parents. For the example above: the container type of A will become D | E, and the container type of B will become D | E, so the container type of C will be determined: D | E.

Problems of the solution

1. Number of container types can grow very fast. Suppose, we add a type F, which extends our type B and one more type G. To have consistent F, we have to share container types of G with A and B and add D | E to G's container types.
2. Container types become senseless. Container types of G can be senseless for types A and B.

[spoenemann]

It would be great to find a generic solution for this. Having more precise container types can make working with the AST easier, and most of the work of implementing a language is about interacting with the AST.

[spoenemann]

A possible solution could be to omit the specialized $container in cases where no sensible type can be found. Then it would default to AstNode | undefined.