Add support for multi-contract calls to unit testing

[mitchmindtree]

On slack it was mentioned that unit testing would be limited to calling into the current contract, however this doesn't need to be the case.

It should be possible to call into all contracts that were declared under [contract-dependencies] whether directly or transitively. We have their src, and can build and deploy them just like we can build and deploy a local contract.

This would make for a good followup to #3262 cc @kayagokalp. Rather than only deploying the project contract, we'd deploy all contract dependencies that exist within the graph.

We will still be limited in the case that a contract attempts to call into another contract that is not declared under [contract-dependencies], e.g. if a contract is constructed from a raw contract ID within Sway code.

This is something we should communicate in the [contract-dependencies] docs and under the Sway contract docs in general - to encourage users to always declare their contract dependencies under [contract-dependencies] if possible as it gives forc the power to do cool stuff like this.

It might be possible to support private contracts (where the src or salt is not known) by extending the [contract-dependencies] feature a little. I'll open a new issue with some thoughts. Edit: see #3572.

[mitchmindtree]

Deploying undeclared contract dependencies

Thinking on this more, a contract dependency must always be declared in the inputs of the transaction in order to call into it from a contract or script.

This implies that it should be possible for us to fetch and inspect the Create transactions of contract dependencies to detect any other transient contract dependencies so that we can fetch those, deploy them, check their transaction inputs for more contract dependencies, and so on. We can potentially integrate this fetching of undeclared contract dependencies during our package graph construction so that we can reason about them alongside the rest of our dependencies.

We should investigate how fuels currently determines what contracts should be present in the transaction inputs, as we can likely do something similar for detecting and determining the IDs of undeclared contract dependencies in workspace members before deploying them.

---

For now, we can stick to deploying declared [contract-dependencies] as we don't yet have infrastructure in forc for querying the fuel network. The package registry (#3752) will require such support, so perhaps we can revisit deploying undeclared contract dependencies in the future.

[mitchmindtree]

On a related note: As scripts may also have [contract-dependencies], we should likely also support deploying all contract dependencies for script tests too (not just contract tests). This would allow for scripts to declare unit tests that test out certain contract interactions before running the real thing.