feat(solc): add dependency graph implementation

[mattsse]

Motivation

Close #739

Solution

Add a dependency graph implementation, see resolve.rs for docs.

Changes

• add a Graph implementation that also resolves all imported dependencies that live outside of the project's configured source dir. This applies the configured remappings during lookup
• Also add those dependencies to the cache file, so changes in a contract/library in the lib folder are detected and trigger a rebuild.
• parallelize as much as possible (reading and parsing of source) files. parallelizing import resolving is not trivial because it can result in duplicated lookups (Lib1 imports Lib3, Lib2 imports Lib3)

ToDos

• version checks, find minimum viable solc version applicable for all dependencies
• integrate in Project::compile

Followup

• add pretty printing like cargo tree

PR Checklist

• Added Tests
• Added Documentation
• Updated the changelog

[gakonst]

seems like we can merge the parallel reading perf improvements independently of the dep graph code?

[mattsse]

@gakonst no idea why abigen tests are failing...
seems unrelated?

[gakonst]

This is really great. A few nits, but nothing blocking

[gakonst]

We're basically double compiling some files?

[mattsse]

I think that's possible in scenarios like:
A(<0.8.10) imports C (>0.4.0)
B(=0.8.11) imports C (>0.4.0)

where A and B are input contracts and C is lib import.
In which case we can't compile A and B together but both require C.
But we only have a single instance of C in our dependency graph.
So I think it's fine to only include it in 1 Solc -> Sources set, like 0.8.11 -> (B,C), because solc will resolve C for A itself if not provided in the standard json input.

the reason why I decided against cloning here is, that these Sources can cause some overhead when we process the cache entries.
I wanted to optimize that first.

[gakonst]

took another look and looks good, no additional comment to my previous ones

[gakonst]

Let's see if this is the solution to all of our problems!