BatchVerifier

[davxy]

This PR targets batching branch

Introduce a batching structure for ring proofs that bundles the KzgAccumulator and the RingVerifier, providing greater flexibility for downstream users.

This would be further improved if KzgAccumulator implemented CanonicalSerialize and CanonicalDeserialize, enabling batching across blocks.

---

Proofs can be prepared for batch verification in parallel. Prepared proofs can be accumulated.
Performance boost ~2x

---

Some benches

Batch vs sequential verification times (ms):

Sequential prepare+accumulate

// | proofs | sequential | batch  | speedup |
// |--------|------------|--------|---------|
// | 1      | 3.032      | 2.790  | 1.09x   |
// | 2      | 6.425      | 3.218  | 2.00x   |
// | 4      | 11.968     | 5.122  | 2.34x   |
// | 8      | 23.922     | 6.487  | 3.69x   |
// | 16     | 47.773     | 10.002 | 4.78x   |
// | 32     | 95.570     | 16.601 | 5.76x   |
// | 64     | 210.959    | 29.484 | 7.15x   |
// | 128    | 422.217    | 52.170 | 8.09x   |
// | 256    | 762.874    | 85.164 | 8.96x   |

Sequential verification scales linearly with proof count.
Batch verification scales sub-linearly.

Parallel prepare + final sequential accumulate

NOTE: Parallel preparation can roughly yield an extra 2x speedup.
The parallel crate feature does not enable this.
Downstream users can perform parallel preparation themselves. Each Prepared proof consumes ~3K, which may introduce significant hidden overhead when preparing big batches, so it may be preferable to accumulate every X proofs rather than the entire batch at once to save memory.

[davxy]

@swasilyev @burdges @drskalman Need some extra attention here.
In practice, instead of immediately using the returned rng, we pick some randomness from it to be used later in the push_prepared

[davxy]

@swasilyev @burdges @drskalman here I pick the randomness back to:

• extend verifier transcript
• and use the derived rng in accumulate