implement request log crawler for consolidation & withdrawal request transactions

[pk910]

This PR adds log crawlers and matchers for the pectra consolidation & withdrawal system contracts.

Both system contracts emit basic log events before queuing incoming operations.
Operations are then dequeued and passed to the beacon chain where they get included in a block as consolidation & withdrawal requests.
Consolidation & withdrawal requests are already tracked by dora.
This PR aims to extend the available request information with further transaction details coming from the execution layer.
So dora can not only show the operation details, but also the origin (tx hash, sender, etc.) on the execution chain.

To achieve this, I've implemented two routines for each request type:

1. consolidation/withdrawal tx indexer:
   This routine crawls the system contract logs from the execution layer.
   The emitted events are processed in order starting from the deploy block, to keep track of the contract queue length internally.
   For each event, dora persists the transaction details, including the operation details, sender + target addresses and the dequeue block number (calculated based on queue length & static dequeue rate).

transaction details are stored in a separate database entity as they may exist before the corresponding beacon operation gets added to the database and vice versa.

2. consolidation/withdrawal matcher:
   This routine tries to match up the separate request transaction & request operation entities.
   It uses the calculated dequeue block number from the transaction entities and loads the corresponding request operations from the slot that includes the el block with that number.
   The matcher routine tries to match each transaction once, ensuring only synchronized block ranges are processed.
   This might leave some late orphaned operations unmatched, but it's an acceptable trade-off compared to processing all unmatched beacon operations over and over again, as some transaction details for orphaned blocks might just not be available anymore.
   For matching requests, the transaction hash is added to the beacon operation entity.

I've also extended the consolidations & withdrawal requests pages to display the matched tx hash (and link it to an el explorer if available).
Additional transaction details are available via a popover:

[skylenet]

Could be good to use different logger identifiers for the different contract indexers. e.g. For this one:
ci.logger.WithField("contract-indexer", "consolidations"),

And for the withdrawal one:
ci.logger.WithField("contract-indexer", "withdrawals"),

And for the deposits one:
ci.logger.WithField("contract-indexer", "deposits"),

Same for the matchers. Replace WithField("routine", "matcher") with something more specific to the matcher.