fix: Figure Out How to Handle `to_block(block_hash)` being reorged during historic streaming

[0xNeshi]

Related #193

Will become relevant after #193 is implemented.

We need to decide what should happen if a reorg happens during historic streaming and the specified to_block no longer exists.

NOTE: since the scanner normalizes from/to blocks, i.e. the client can set to_block to be lower than from_block, when we refer to to_block in this issue, we refer to the block with the higher block number post-normalization.

[0xNeshi]

One course of action is to do nothing, i.e. rely on the client receiving ReorgDetected and realizing that their ending block with the hash they specified no longer exists. They can then either choose to ignore this notification and let the historic stream handle the reorg, or they can choose to handle this case in a different way (e.g. stop the stream and reinitialize the scanner).

@LeoPatOZ