Make block ranges vs sequence ranges less confusing; ensure at compile time that indexer and cursor pairs have consistent range types

[tkporter]

After this task, we should have:

• less confusing treatment of sequence ranges vs block ranges. E.g. the current pattern of returning a single RangeInclusive that can mean either a block range or sequence range is pretty confusing. Consider something like Dan's suggestion here Sequence-aware indexing refactor #3262 (comment)
• We shouldn't need to implement SequenceAwareIndexer for types that don't involve sequences. E.g. atm we need to impl SequenceAwareIndexer<InterchainGasPayment> for Cosmos and Ethereum, when we don't actually need it. It just returns None as the option
• Possibly remove Indexer as a supertrait of SequenceAwareIndexer
• For an Indexer + Cursor pair, we should have a compile-time guarantee that they agree on what indexing range mode they use (sequence range vs block range). See picture in https://www.notion.so/hyperlanexyz/Indexing-Refactor-7220f23de5fd4592beb30af801b6f61a?pvs=4#799205eedd7741baad03d4174ec73ede for details. Leading idea is to within ContractSync, store (Indexer, Cursor) pairs as variants of an enum that enforces either Block or Sequence traits. Alternatively, the enum could be replaced by dynamic dispatch.