Improve code quality in ZKPs

[marsella]

There are some common issues across the zero-knowledge proofs in the repo that should be addressed. Broadly, these include:

• Loose typing. The proofs use relatively generic types for many of their inputs. Being more specific will make it harder to misuse the proofs.
• Non-descriptive naming. The proofs take variable names directly from the paper, which means a lot of single-letter names. Especially when combined with the types, this makes it difficult to semantically parse the proofs or audit whether the inputs are correctly defined. Adding descriptive names will make this easier (perhaps with documentation of the original short names to cross-reference with the paper).
• No documentation. None of the proofs document what they're proving.
• General Rustiness. This is a broad and hard-to-define category. Some of the tickets have specific bullets about, for example, using Rust Vecs in a canonical way (iterators and repeat_with vs pushing new elements onto a mutable Vec), but "Rustiness" tasks are not exhaustively covered in the issues. Generally speaking, using paradigmatic Rust will make it easier for auditers and new developers to read and understand the code.

The issues in this epic each capture a single proof and include all of these items (plus any specific/unique code quality issues). The theory is that solving any one of the problems will give useful context for the others, so it'll be easiest to address all the problems in one fell swoop. If PRs are becoming too massive, we can re-evaluate.

There are also two API-level changes that will affect this code quality improvement. The ZKP Proof trait currently doesn't expect a transcript, but some proofs are chained together and should have a transcript that includes material from earlier proofs (#49). The AuxInfoProof is a zero-knowledge proof, but doesn't implement the proof trait; we should use this even though it's a "composite" proof (#53).

Note: This epic doesn't include improving tests for each proof. However, once someone completes a ticket here, they will be well-equipped to take on the corresponding test ticket from #45, since they'll have the whole proof phased into their head.

[marsella]

For reference on what kinds of documentation we'd like to see on the ZK proofs, here are some examples from our other zk proof library, zkchannels-crypto. It's not a perfect representation -- since that was a proof builder, there was a lot of module-level documentation and less per-proof docs. In this library, I'd expect mostly per-proof docs. But anyway:

• module docs
• individual proof example
• individual proof with full doc example