feat(forge): Support library linking

[brockelmore]

Adds support for library linking at deploy time. Works by determining dependencies, calculating address in correct order, linking the dependency addresses recursively on the way up to a target contract, and deploying dependencies before deploying a test contract.

Todo:

• create command support
• run command support
• merge upstream changes into ethers-rs

[brockelmore]

Closes #222, Closes #349

[odyslam]

woot

[brockelmore]

dropping trying to support create as it is kinda counter-intuitive for that command to deploy multiple contracts

[onbjerg]

dropping trying to support create as it is kinda counter-intuitive for that command to deploy multiple contracts

how does dapptools do it? ig u deploy lib manually and then pass it as an opt?

[brockelmore]

how does dapptools do it? ig u deploy lib manually and then pass it as an opt?

ye - we already support dapptools style compile-time linking. also the official solidity docs recommend not manually linking and letting the compiler do it. For contracts going on mainnet, I tend to agree.

[onbjerg]

any chance we can dedupe the linking part by extracting it as a function?

[brockelmore]

ye we probably can - there are some differences between the two but probably can be combined 90%

[mattsse]

halfway through
highlighted the things that stood out.
need another stab at it to fully understand what's going on

[gakonst]

approving cautiously, given integration tests seem to pass I feel OK about it.

2 things as follow-ups:

1. Is there any large real repo with libs and linking which we could use as an integration test?
2. Should we upstream these into ethers-solc?

Feels like we should do a full review of ethers-solc / or a writeup because the pipeline has gotten quite complex at this point

[brockelmore]

approving cautiously, given integration tests seem to pass I feel OK about it.

2 things as follow-ups:

1. Is there any large real repo with libs and linking which we could use as an integration test?

2. Should we upstream these into ethers-solc?

Feels like we should do a full review of ethers-solc / or a writeup because the pipeline has gotten quite complex at this point

1. I tested with Scott Sumarto's library who opened the Lib.Enum issue. It is private for now, but when it opens up i think it should be a good test as he rated it as "as complex as it can get" for library linking and we verified the linking together.
2. maybe? there are some intricacies here that make me say no, but i would be okay with it

we should def do a writeup/review, lmk how you want to proceed on that front

[brockelmore]

Closes #612 but we should open another issue for decoding collided function signatures