fix(forge): selectively enable Etherscan trace resolving when a test in ran in a forked environment and return block number in trace on a failed test

[zerosnacks]

Motivation

Closes https://github.com/foundry-rs/foundry/issues/7555 (bug) Closes https://github.com/foundry-rs/foundry/issues/7312 (bug) Closes https://github.com/foundry-rs/foundry/issues/7574 (feature)

In short, when an ETHERSCAN_API_KEY is defined in a users' .env it would trigger Etherscan trace resolving for local tests which would result in a massive slowdown after running into rate limiting.

Solution

Implements a way to mark test results as whether having ran in a forked or non-forked environment. This is then used to selectively enable or disable Etherscan tracing (without re-initializing).

As requested in #7574, upon a encountering a test failure in a forked test it will now display the fork block number. On succesful runs it is not displayed.

Known limitations:

• Generally unable to differentiate remote forks and local forks
• When using vm.roll(n) local forks are created

Given that trace caching is now resolved these limitations are not that big of a deal, at worst the experience is as bad as it is now but only for the initial run.

The chosen approach was to add high-level context tracking which can easily be expanded to track additional call context related information.