Epic: Add scraper support for Cosmos

[tkporter]

The scraper makes a few EVM-centric assumptions, but nothing excessive. You can think of the work as roughly: "change the scraper to not be EVM-centric, implement some Cosmos-specific code, make sure we can test this, and deploy"

In chronological order & each containing day estimates:

Note: sequencing-wise, it may make sense to coordinate with https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4271 for many things including shipping this

### Cosmos scraping
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4345
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3330
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3332
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/4300
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3355
- [ ] https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3356

based on research completed in https://github.com/hyperlane-xyz/issues/issues/903

Related: https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3346

[tkporter]

A "scratch pad" for my thoughts as a dove in:

• Why does it need to use the forward message sync cursor instead of the forward backward? Feels like forward backward is better

• Why do we have so many rows in cursor?

  • seems like we insert a new one each time we update the watermark, why? why not just update?

    select count(*) from cursor;
    count
    ---------
    9688274
    (1 row)

• Why is cursor even required?

  • this is for the watermark cursor. It seems like we use the same watermark for IGP and delivery indexing, which isn't ideal

• We should probably change all insertions to be robust to conflicts so we can avoid situations like what we got into earlier around block hashes. See https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/rust/agents/scraper/src/db/message.rs#L226 as an example

Changes to schema required:

1. Our address type isn't 32 bytes. Should it be?

/// Addresses are to be stored as binary.
#[allow(non_upper_case_globals)]
pub const Address: ColumnType = ColumnType::Binary(BlobSize::Tiny);

Maybe this isn't so bad? But this feels awkward - would probably be easier to keep everything as 32 bytes. Worth considering the explorer situation.

We use address_to_bytes in various places to convert H256s like senders / recipients / mailbox addresses to a 20 bye representation, which is very EVM specific.

This is used: a. message table: sender, recipient, and origin mailbox b. delivered_message table: destination_mailbox

2. unsigned doesn't do what we want - we need a larger data type https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3121

3. transaction is very ethereum-specific:

   id  |        time_created        |                                hash                                | block_id | gas_limit | max_priority_fee_per_gas | max_fee_per_gas | gas_price  | effective_gas_price | nonce |                   sender                   |                 recipient                  | gas_used | cumulative_gas_used
   -----+----------------------------+--------------------------------------------------------------------+----------+-----------+--------------------------+-----------------+------------+---------------------+-------+--------------------------------------------+--------------------------------------------+----------+---------------------
   299 | 2023-10-20 21:35:29.902644 | \xff8c550fd9d8311983af61ece61ba0983312e191e6fa0ea076540cc0749ea386 |      293 |    305335 |               1500000000 |      1500000100 | 1500000050 |          1500000050 |    76 | \xfad1c94469700833717fa8a3017278bc1ca8031c | \x086e902d2f99bcceaa28b31747ec6dc5fd43b1be |   250733 |              297586

   We don't need cumulative_gas_used. The rest are probably ok to keep tbh