Support queuing multi-block downloads and executing ranges of blocks after a forkchoice update

[Rjected]

Describe the feature

Currently we only support queuing single block downloads via the FullBlockDownloader. With #3059 we will have a heuristic for the number of blocks that need to be downloaded and executed to validate a forkchoice update. This is done by first fetching the head or safe block hash, and comparing the block number with the latest valid finalized block.

Instead of downloading the missing blocks one-by-one, we should support requesting ranges of blocks, since #3059 will already use the block number range to determine whether or not we should run the pipeline. This is more efficient than traversing the missing parents one-by-one.

Additional context

No response

[mattsse]

we definitely need to do this, ideally if range is larger than x blocks, perhaps even as low as 4, but really depends on how fast we can execute them.

the responses need to be yielded with increasing block number so they can be appended to the chain.
somewhat related: #3276

[onbjerg]

Closed in #3416