Item dependency graphs and yulgen salsafication

[sbillig]

Functions, contracts, and struct items now have dependency graphs. A function depends on the functions it calls and any types that are present in the function signature or body (and on anything in the dependency graphs of those items). A type depends on the types of its fields (but not its functions; those are only included if they're called).

A contract runtime object is built by traversing the dependency graph of its (as yet imaginary) __call__ function, which is the union of the dependency graphs of the contract's public functions (implemented in contract_runtime_dependency_graph).

The constructor object is built by traversing the graph of the contract's __init__ fn, which means we no longer have to include the entire world in the constructor object "just in case".

The (directed) edges in the dependency graphs are labeled with DepLocality::Local or ::External. An "external" edge between items means that the items will exist at different addresses when the code is deployed; eg calls to external contract functions result in "external" edges. (Note that this is orthogonal to whether the items are in the same "ingot"). When compiling a contract, we include all items reachable by traversing only "local" edges. "External" edges will be used for future 'unused item' warnings.

Inclusion of contract objects that are create/create2d is handled by checking the CallType of every call by every function in the dependency graph. This should probably be reworked; maybe an explicit "creates" relationship should be modeled in the dependency graph, or in a separate graph.

This is only a partial re-organisation of the yulgen code; some functions became salsa queries but others didn't, somewhat arbitrarily. More cleanup could be done, but not today.

closes #299
closes #305

To-Do

• Add entry to the [release notes]
• Clean up commit history

[g-r-a-n-t]

LGTM 🎊