feat(zero-bin): add support for 2-to-1 independent block proofs aggregation

[Nashtare]

We'd want to add another prove / verify pair.

The job queue would consist in independent (i.e. distinct chains) final block proofs to be submitted (each possibly representing an entire sequence of consecutive blocks from a single chain past a known checkpoint height), to be aggregated in a binary tree fashion.

Because the aggregation statement hashes a block proof PublicValues, and 2-to-1 hashes (i.e. compresses) two aggregated proofs' own PublicValues hashes, the verifier would need to be passed, in the clear, a sequence of PublicValues with necessary metadata to help them reconstruct the final root hash to be used as public input when verifying the proof. ¹

Follow-up work from #318 and #364.

Blocked by #525

Footnotes

1. or rather, to be verified against the encoded public values already attached to the proof payload. ↩

[Nashtare]

From a design perspective, I'm not so clear as to how the prover interface should look like on zero-bin side, partly aligned with the motivation behind #447.

Motivation

We want to have two distinct proving modes:

• a regular, on-chain block proving mechanism, as we currently have, that supports 3 different input modes Rpc / Stdio / Http.
• a cross-chain, independent block proof aggregation mechanism, to combine multiple unrelated block proofs coming from different chains before submitting the final "batch" proof. The base work for this was tackled by Two to one block aggregation #318 and
  Add necessary 2-to-1 aggreg. components for proof_gen #364.

Base work for the paladin operations / zero-bin adaptation has been started on two_to_one_zero branch.

Issue

Adding another mode comes with some design considerations:

• we already have a lot of CLI args (and actually 2 more to come with feat/continuations).
• most of the sub args for the 3 input modes above are actually irrelevant when it comes to the block aggregation mechanism
• we may want to limit the kind of input sources available for one mode or the other (I don't think we've ever used the HTTP mode, will we ever?)

Ideally, we'd want to be aligned with how we want this to look like before I continue further and start shaping the new CLI.
@0xaatif @atanmarko Any opinion welcome :)