Refactored Type Checking and Analysis Annotations

[ekpyron]

What

Make type checking robust against several invocations (creation mode; runtime mode), as well as out-of-order execution, even in the presence of cycles.

Why

To enable compile-time constant expression evaluation and the code data location, as well as making support of generics easier in the future.

What

Currently, the Solidity AST is const after parsing and then annotation()-annotated by the analysis steps in CompilerStack::analyze.

However, some AST nodes and some Types have interfaces that implicitly depend on annotations. (e.g. for types: ContractType::stateVariables, StructType::nativeMembers; e.g. for AST nodes: StructDefinition::type, VariableDeclaration::hasReferenceOrMappingType, etc.).

In the past we regularly had ICEs due to such implicit dependencies. That has gotten better recently, but it's still an easy source of error.

This issue is going to get worse, once we want to move to compile-time constant expression evaluation since this will probably entail switching multiple analysis steps to simultaneous cycle-resistant lazy-evaluation.

Furthermore we need to evaluate additional requirements looking ahead to type checking in the presence of future generics.

So we need to come up with a nicer way to:

• Make all implicit dependencies of AST node and Type interfaces explicit. If possible, even syntactically prohibit errors (as in "too early use").
• Make the relevant parts of type checking and analysis procedure robust against out-of-order lazy evaluation.
  • Since array lengths should be allowed to be calculated using compile-time constant expressions, this at least entails DeclarationTypeChecker and TypeChecker, with implicit interactions with ContractLevelChecker.

Notes

• Direct prerequisite of Compile-Time-Constant expression evaluation #13318 and Reference type immutables #13723
• Prerequesite for generics

[ekpyron]

Given #12932 there may be cause to do something similar even as early as the NameAndTypeResolver - this does not necessarily have to be done in one go, but it's something to keep in mind here.