core/state, trie: improve parallelization of account and storage trie hashing

[jwasinger]

closes #32922

This PR makes a modification so that the value of a leaf trie node is not needed at insertion: a resolver (function which returns the leaf value) is provided at insertion, and the resolver is invoked later when the value is needed (e.g. hashing or value retrieval). This enables the account and storage tries to be hashed simultaneously: if an account's storage trie is still being hashed, an attempt to hash that leaf node in the account trie will block until the value can be resolved.

It has an additional benefit for BAL:

For any account that is modified, only the mutated fields will appear in the access list. To update the account in the trie, all state account fields must be written. Parallelizing the fetching of the intermediate nodes from the trie and the fetching of prestate values from the snapshot will be useful for speeding up the update of the state trie.

The changes in this PR lay the initial groundwork that is required to implement this optimization.

It's WIP:

• I'm currently running a benchmark of it on 7/8
• Verkle/Binary broken by this change, but it should be an easy fix.

[jwasinger]

It improves the time to compute the state root (account update + storage update) by 55% .

I tried switching machines, and for some reason bench7 runs slightly faster than bench8... Perhaps the benchmarkers have burstable disks and 8 is getting throttled.

[jwasinger]

Original speedup calc was wrong. The trie hashing is (account update + storage update + account hashing). It's a ~23% speedup for total trie hashing time with this PR.

[jwasinger]

Longer timespan measuring block processing following the tip of the chain, with the performance diff between the two nodes having been smoothed out (this branch is bench8, master is bench7):

[jwasinger]

#33037 accomplishes practically the same thing as this PR and it's less complex.