[spike] Assess usage of external Eth libraries in Forest

# Summary

## Problem

When implementing FEVM RPC methods we add a lot of complex code with Ethereum-specific details. Most of this code comes from Lotus (which is NOT exactly an Ethereum node implementation). This is both difficult (lots of discoveries) and bug-prone as we are not primarily Ethereum developers and might miss some nuances.

Can we avoid re-implementing Ethereum logic?

## Idea

There are libraries that should contain at least a part of logic we need. We would still need to do some translation between Filecoin and Ethereum transactions, but it may be that we can omit re-implementing some logic (such as signature verifications, [Solidity ABI helpers](https://github.com/ChainSafe/forest/blob/c7a500dcfa31608e1db99be4253832255de7c7df/src/rpc/methods/eth.rs#L878-L907) etc.)

## Upsides

- we re-use a thoroughly tested, optimised and likely audited code (and can potentially find FEVM bugs in Lotus),
- we don't spend time re-implementing existing software and focus on business logic,
- we (potentially) contribute to existing Ethereum ecosystem
- we might be faster in implementing FEVM features than Lotus/Venus if we can just call an existing library functionality

## Downsides

- we have less control over the Eth methods,
- initial cost of migrating

# Completion Criteria

- [ ] assess the existing Rust Ethereum libraries (for example https://github.com/paradigmxyz/reth?tab=readme-ov-file#using-reth-as-a-library) and whether we can use them in Forest,
- [ ] if the above is feasible, assess the effort to perform a migration from our own implementation to an existing one.

# Additional Links & Resources