(WIP) Add support for Yul AST nodes (addresses #163)

[d1ll0n]

Work in progress, not ready to merge

This is not ready yet, I'm just creating a PR to make it easier to track progress.

Summary

Introduce typed yul AST nodes with the same rich feature-set as solc's AST nodes. For more context, see #163

TODO

Features

Complete

• Create classes for every Yul AST node type.
• Add processor files for every Yul AST type to src/ast/modern
• Add make and copy support to ASTNodeFactory
• Replace the Yul AST writers with ones based on ASTNodeWriter that produce structured SrcDesc outputs.

TODO

• Add new scope resolution methods to recognize YulBlock, YulForLoop, YulFunctionDefinition as scopes and recognize YulVariableDeclaration and YulFunctionDefinition as definitions.
• Add pretty printers in src/types
• Add types for the builtin assembly functions in src/types
• Add constant evaluation support
• Come up with some sort of node to represent member access of the form (>=0.7.0 sptr.slot, sptr.offset),(>=0.7.5 cdptr.offset, cdptr.length), (>=0.8.10 extfnvar.address, extfnvar.selector), (<0.7.0 sptr_slot, sptr_offset) and disambiguate with identifiers containing a dot (allowed in >0.5.7 <0.7.0)

Tests

• Create specific unit tests for the Yul AST nodes.
• Remove workarounds introduced in aaf54ed 7949cc6 and update the tests. Will need to prove that the same data is present between versions for the formatter and determine a Yul ID generation methodology acceptable to the team.
• Create testing framework for scope resolution of Yul AST nodes. We don't have the benefit of solidity's referenced declarations here, so I think we'll need to do constant evaluation and compare to the EVM. Discussion: Add support for Yul AST nodes #163 (comment)

[blitz-1306]

Great job. Would like to highlight one option.

[blitz-1306]

Another option here is to consider using second standalone ASTContext for Yul nodes...

It seems a bit more clear and sound, however it would have more impact on code overall. Some pros/cons:

1. It would be easier to keep it clean, as Solidity AST will not conflict with Yul AST references ever.
2. There would would be no need to have hacks like 1e5, as ID space is separated.
3. ASTReader and ASTNodeFactory would have to track two different AST contexts. Maybe YulNodes would also be affected if they refer to any ASTNodes as referenced declarations...

Unsure about consequences here. It may look cleaner but may also be impractical in the end. Still, I guess it may worth an attempt to see what would happend.