Always fetched finalized blocks by hash

[jbearer]

We had an incident in mainnet caused by some nodes having different cached finalized L1 blocks for the same block number, which should not be possible. We theorize that this can happen due to fetching finalized blocks by number. We assume that if we no block n is finalized and we fetch block n - k, it must also be finalized. However, if we have an L1 client failover (or the L1 provider itself fails over to a different node, as we suspect happened with Infura) it is possible that we observed n was finalized from one RPC node, but then we try to fetch n - k from a different RPC node which hasn't finalized n yet, and returns an unfinalized block for n - k which is later uncled.

This PR:

• Modifies get_finalized_block in the L1 client to start from a known finalized block (either one which is already cached or one which is explicitly fetched using the finalized block tag) and then work backwards by parent hashes, fetching blocks by hash so we know we get only blocks which are in the finalized chain, until reaching the desired block
• Adds parent_hash to the information we cache about each L1 block

Note that in the worst case, this could increase the number of blocks we fetch from the RPC. However, in the very common case, the latest finalized block (the one returned from fetching the finalized tag) is exactly the block we are trying to fetch, and we don't have to do anything else.