feat: inject contract id into the namespace for tests automatically

[kayagokalp]

closes #3673.

About this PR

This PR adds CONTRACT_ID injection while building contracts with forc build --test. CONTRACT_ID is the id of the contract without the tests added. To find out that id, we first compile the contract without tests enabled.

The rough outline of stuff happening here:

1. We iterate over BuildPlan members to find out contracts and collect their contract id into an injection map. In this step only the contracts are built. To determine contract id we need to compile the contract without tests. Since we also need the bytecode of the contract without tests, we are collecting them as we come across them while iterating over members.
2. With the injection map build and execute all the tests, so basically after first step we are just doing the old forc-test behaviour.

So basically I added a pre-processing step for contract id collection for those members that require it (contracts).

This enables the following test structure:

let caller = abi(MyContract, CONTRACT_ID);
let result = caller.test_function {}();
assert(result == true)

TODO

• Documentation

[mitchmindtree]

Excited for this!

That said, I don't think we should be distinguishing between contract and non-contract in forc-pkg itself like this, as the difference is not particularly relevant to forc-pkg and is only a concern of forc-test.

We should aim to make the minimum changes possible in forc-pkg. Namely, we should only need to add the ability to optionally add an item to a package's namespace when building it (so that we can add the CONTRACT_ID).

Rather than having forc-pkg special-case contracts, I think we should instead do something like the following:

1. In forc-test, rather than building the whole workspace, iterate over members (in the correct order) and only build the contract members without tests.
2. Add an option to forc-pkg build functionality that allows for injecting item(s) into a package's namespace.
3. In forc-test, rather than building the whole workspace with tests at once, iterate over the members (in the correct order) and inject the CONTRACT_ID into contract members as necessary.

This might end up being slightly more verbose, but should help to keep a clearer separation of concerns between forc-pkg and forc-test. Thoughts?

[kayagokalp]

I wasn't really happy with how this turned out tbh, thanks for the comment @mitchmindtree! I think the proposal seems it would be a lot cleaner. I will come-up with the implementation tomorrow morning 👍

[kayagokalp]

This should be good to go for another review, I will be introducing a general refactor to forc-test to address some of the left over review comments from earlier PRs.

[mitchmindtree]

Nice, this new approach is looking much better! Just a few nits we should address first.

[mitchmindtree]

Nice, exciting stuff! 🚀

I've left a couple of optional suggestions, but none are blockers.