refactor: txgossip.NewBlockChain() serves executed not settled state

[ARR4N]

The upstream legacypool implementation expects a synchronous blockchain, initially requesting the current block and then updating based on chain-head events, in both cases opening a state.StateDB at the latest types.Header.Root. In an asynchronous implementation this results in the mempool acting on settled, not executed state. So far this has caused two undesirable properties:

1. $\tau$ seconds of empty blocks. Until settled, included transactions remain in the mempool, unblocking sae.VM.WaitForEvent(), only to be filtered out by worstcase. This also suggests an underlying inefficiency in which every BuildBlock() first discards some prefix of already-included transactions.
2. VMs recovered after shutdown may experience a false nonce gap (see hack in feat: VM restart with database recovery #160) that don't allow their BuildBlock() method to include any transaction from an EOA with included but not settled transactions.

This PR introduces a mapping from settled to latest-known execution roots, opening the latter whenever legacypool requests the former. The latest-known property accounts for the fact that multiple blocks may settle the same state root while introducing different post-execution roots. Although this doesn't address all of (1) and some empty blocks and discarded prefixes can occur, it significantly curtails the issue.

Instead of introducing a new test in this PR, I have demonstrated in f314e32 that this fixes the hack required by #160.

[ARR4N]

Unnecessary if we just return head regardless of which state root is requested (idea thanks to @StephenButtolph).