feat: use new ChainHardforks type on ChainSpec

[joshieDo]

With the eventual goal of removing the optimism feature, this PR introduces a new type that represents hardforks inside a ChainSpec.

pub struct ChainHardforks {
    forks: Vec<(Box<dyn Hardfork>, ForkCondition)>,
    map: FxHashMap<&'static str, ForkCondition>,
}

ChainHardforks only implements methods that interact with the list of an object that implements the trait Hardfork: eg. fn is_fork_active_at_block(...), fn fork(fork), etc

More chain specific methods are implemented with traits, eg:

pub trait EthereumHardforks: Hardforks {
    /// Convenience method to check if [`Hardfork::Shanghai`] is active at a given timestamp.
    fn is_shanghai_active_at_timestamp(&self, timestamp: u64) -> bool {
        self.is_fork_active_at_timestamp(EthereumHardfork::Shanghai, timestamp)
    }

And finally, each chain can have their own specific hardfork enums: EthereumHardfork, OptimismHardfork.

Eventually, every chain specific type will go to their node's crate.

Another important thing to highlight is that now Hardfork does not implement Ord, and so, each chain Vec should be declared in the desired order.

[mattsse]

directionally this is what we want, but we can improve how we lookup forks because iterating over a ton of hardforks isn't ideal if we only need to lookup names

[mattsse]

last pedantic nits,

couldn't find the op hardfork activation blocks, we should keep these similar to the ethhf activation functions, because i still think this info is nice to have

[mattsse]

In a followup we can duplicate this into two, one for eth and one for op

[DaniPopes]

Suggested change

	) -> impl Iterator<Item = (&Box<dyn Hardfork + 'static>, ForkCondition)> {
	) -> impl Iterator<Item = (&dyn Hardfork + 'static, ForkCondition)> {

[joshieDo]

this causes some issues on Chainspec::latest_fork_id regarding lifetimes with self

[joshieDo]

did a workaround by doing this, and adding a fn last for this particular case.

[mattsse]

lgtm,

pending @DaniPopes

[mattsse]

@DaniPopes this requirement currently prevents us from doing Arc<dyn Hardforks>

I'm sure we can work around this, but we should do that separately.