Cardano Blocks + Transactions certification - Phase 1

## Why

We need to certify the blocks and provide a way to verify the membership of a block in the Cardano chain. In order to do so, we want to create a new certification in the protocol:
- Certification of the block hashes + transaction hashes set (with block depth from tip of the chain at the moment of snapshot creation)
- On demand generation of a membership proof for a subset of block hashes or transaction hashes

## What

Certify the blocks from the Cardano chain and provide some on-demand proof of membership.

The design is similar to what has been done in #1457, with the following differences:
- Blocks and Transactions must be clearly distinguished with Domain Separation Tag (DST)
- Sorting of blocks and transactions in Merkle tree is critical and will follow:
1. All the Blocks of a Block Range (sorted by block number and block hash)
2. Then all the transactions (sorted by block number and transaction hash)
- Proving of Transaction/Block will be done by Transaction Hash/Block hash even though more information is stored in the Merkle tree (on 2 logical routes).
- Hash functions will likely be SNARK friendly (e.g. Poseidon)
- The database structure is more relational (for blocks referenced in transactions) with a table for blocks (and is shared with `CardanoTransactions` signed entity type)
- Some throttling of imports of Blocks/Transactions will be applied to be even more gentle with SPO's infrastructure

### Aggregator (certification)
[]((https://github.com/user-attachments/assets/b71b7940-5fc9-4db9-8c55-c68f8ee19053))

### Signer (certification)

[](https://github.com/user-attachments/assets/bfeadb93-c433-473c-9bdf-1ecaf0501c71)

### Aggregator (transaction/block membership proof)

[](https://github.com/user-attachments/assets/1a88d605-7ed9-43ed-93a5-50a5b5990445)

## How

- [x] #2905
- [x] #2907
- [x] #2909
- [x] #2908
- [x] #2955
- [x] #2956
- [x] #2971
- [x] #2987
- [x] #2988
- [x] #3031
- [x] #3032
- [x] #3100