feat: allow extending foundry for non-EVM chains via strategy implementation

[nbaztec]

Motivation

As part of #7624 this would form a way to start formulating an approach in order to extend foundry functionality to non-Ethereum/EVM chains in the least invasive way possible.

These "strategies" can be overridden by forks to implement their own functionality, as is demonstrated in foundry-zksync. At the very least, this gives a place for forks to add custom code that can be called in an idiomatic way, until it can be formulated as an upstream PR.

As an initial step, we went with a dynamic dispatch instead of generics as the generic would be required to be propagated to numerous places, and this PR serves as a good start to initiate a discussion on this approach.

Solution

In places of interest - Executor, Backend and Cheatcodes (identified so far), a stateless "strategy" would be provided that works with a context object Box<Any> that may be mutated. This allows for forks to implement their own behavior and keep their state separate in the context. The standard "foundry way" is currently encapsulated in the EvmStrategy, which is the default.
Forks are expected to modify the utils::get_executor_strategy(&config)(example) to return a strategy of choice depending upon the config.

Future Goals

The stateless nature of strategy makes it possible to remove the &self objects, which are currently required for object safety, and thereby being declared on the generic type.