Indexing Modularization

[fernandomg]

From @nambrot feedback:

Explore the possibility of providing ABI, a parser and a union type.

Define our own types (instead of just using the Typechain types) to have shared fields or semantics of the intents.

So in listener, eventually we would need some kind of transformation logic in the listener subclasses, I assume that's what parseEventArgs is for

Eventually we also want to support getting intents not from indexing contracts, but any source, so I suspect the current base listener is not actually the base, but there will be a ContractIndexingListener

---

Our core idea is to eventually have a unified interface between listener/indexer and filler, so the user can use some generic indexer to feed a custom filler or viceversa.

Up to now, from what we gathered, comparing Hyperlane7683 vs Eco intents, there's not much room for us to standardize a filler for both intents.

---

But, please, elaborate more around this topic. I'm certainly missing some key points here.

/cc @tmsrjs @pablofullana @lmcorbalan