refactor(l1,levm): remove coupling LEVM and REVM

[JereSalo]

Motivation

• Try to stop using EvmState whenever possible. (except for when we use REVM, of course)

Description

• We want to use EvmState only in cases in which we use REVM, not for LEVM methods!
• LEVM uses its own get_state_transitions, there is no need for using EvmState in it but remember that we can't use ExecutionDB with LEVM!
• Now we have an EVM struct that has an EvmImplementation enum and a Store.
• We don't pass ass parameter in EVM methods anything that can be accessed with Store.

Note: There are still functions that are both for LEVM and REVM and therefore they tend to have the parameters each EVM needs. In the case of REVM we need state: EvmState, and in the case of LEVM we need block_cache: CacheDB. We probably want to avoid passing these things as parameters.

We also want to decouple our VMs from Store but maybe that's a change for a following PR.

Note 2: We decided to keep EVM stateless because stateful had complexity attached to it. See #2096

[github-actions]

| File                                                                     | Lines | Diff |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/cmd/ef_tests/state/runner/levm_runner.rs | 359   | -7   |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/cmd/ef_tests/state/runner/revm_runner.rs | 529   | -3   |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/cmd/ef_tests/state/utils.rs              | 74    | +10  |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/cmd/ethrex/ethrex.rs                     | 433   | +3   |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/crates/blockchain/blockchain.rs          | 282   | +2   |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/crates/blockchain/payload.rs             | 566   | -3   |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/crates/l2/proposer/l1_committer.rs       | 378   | -3   |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/crates/vm/backends/levm.rs               | 437   | -12  |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/crates/vm/backends/mod.rs                | 203   | -81  |
+--------------------------------------------------------------------------+-------+------+
| /home/runner/work/ethrex/ethrex/crates/vm/backends/revm_b.rs             | 650   | +96  |
+--------------------------------------------------------------------------+-------+------+

Total lines added: +111
Total lines removed: 109
Total lines changed: 220

[mpaulucci]

I was hoping that we could decouple the vm from storage. I think the vm should not be aware of the storage crate.

Instead, it would be ideal if vm could define an interface for the state access it needs and blockchain could implement that interface by calling methods from storage.

So that our dependency tree can look more like this: https://www.mermaidchart.com/raw/4e4ac69d-5149-40e8-92f2-2466890c2893?theme=light&version=v0.1&format=svg

Thoughts?

[JereSalo]

I think I can do something about it but maybe in a subsequent PR (or at least after making sure nothing breaks in the decoupling). I like the idea though!