perf(engine): paralellize evm_state_to_hashed_post_state()

[figtracer]

according to benchmarks, this increasingly improves perf if accounts accessed >20, below this value a sequential approach is more beneficial due to overhead

[gakonst]

Nice - what's the impact of this overall?

[figtracer]

the function is called by the payload processor MultiProofTask::on_state_update() when we have state changes

i got these results when benchmarking on my machine

Accounts Accessed	~Before (µs)	~After (µs)	~Speedup
10	31	38	0.82x
20	61	51	1.2x
50	289	125	2.3x
100	571	214	2.7x
200	1,200	387	3.1x
300	1,810	560	3.2x

i think there's another PR working on this as well #20475

[mattsse]

imo this makes a lot of sense

we can even simplify the collect impl with #20653

[mattsse]

this we can simplify with

#20653

after

[figtracer]

on it

[figtracer]

there's potentially another optimization, similar to this one, here:

reth/crates/engine/tree/src/tree/payload_processor/prewarm.rs

Lines 768 to 779 in 05b3a86

	fn multiproof_targets_from_state(state: EvmState) -> (MultiProofTargets, usize) {
	let mut targets = MultiProofTargets::with_capacity(state.len());
	let mut storage_targets = 0;
	for (addr, account) in state {
	// if the account was not touched, or if the account was selfdestructed, do not
	// fetch proofs for it
	//
	// Since selfdestruct can only happen in the same transaction, we can skip
	// prefetching proofs for selfdestructed accounts
	//
	// See: https://eips.ethereum.org/EIPS/eip-6780
	if !account.is_touched() || account.is_selfdestructed() {