feat: add preprocessing support

[shuklaayush]

• Added a setup phase that generates a ProvingKey and a VerifyingKey. The ProvingKey stores all the preprocessed traces involved when proving multiple AIRs and information on how they're committed. The VerifyingKey stores the commitments.
• Updated the prover/verifier to accommodate preprocessed traces
• Added a check_constraints function for debugging RAP constraints

[jonathanpwang]

The per-air modifications look good, most comments are nits.

But right now the prover / verifier is only taking partitions[0].airs for preprocessed - is that because you were still iterating?

Also as discussed, the proving key for multi AIRs should either keep a separate preprocessed commit per AIR, or a nice-to-have is to allow a list of commits and arbitrary assignment of single AIR preprocessed trace to commit.

We can save the latter to a coming-soon refactor: I'm starting to think that is a better structure than the partition structure.

Recording off-line conversation about motivation: if we have a single machine with fixed chips, then it makes sense to share a preprocessed commit across matrices. However if we have a machine where some chips (precompiles) are only added some of the time, then we don't want to rebuild the global machine proving key for each subset of chips.

[shuklaayush]

But right now the prover / verifier is only taking partitions[0].airs for preprocessed - is that because you were still iterating?

Yes, I'm still trying to understand the structure and need some clarification. This is how I'm thinking about this:

We have a machine with a fixed set of AIRs that can be a part of the execution. We divide the execution into partitions and prove them independently. If each partition contained traces for all the machine AIRs, you could store a global proving/verifying key that includes all the preprocessed traces and a single commitment to each.

But I guess what you're saying is that a partition might only contain a subset of the machine AIRs:

// ------------------------------------------
// Partition1
// Prep[0] | Main[0][0] | Permutation[0][1] |
// Prep[1] | Main[0][1] | Permutation[0][1] |
// Prep[2] | Main[0][2] | Permutation[0][2] |
// ...
// ------------------------------------------
// Partition2
// Prep[0] | Main[1][0] | Permutation[1][1] |
// Prep[2] | Main[1][2] | Permutation[1][2] |
// ...
// ------------------------------------------
// ...

Since each partition is heterogeneous, you only want to include and commit to preprocessed traces of AIRs that are part of this partition. In that case, should I store the commitment to each preprocessed trace separately in the proving/verifying keys? I'll also need to store a mapping from the partition AIRs to "global" AIRs.
Another option could be to have separate proving/verifying keys for each partition that only contain preprocessed traces involved in this partition

[jonathanpwang]

The partition logic was only for the main traces, so I think it needs some rework.
Basically the preprocessed are partitioned separately from main, which is partitioned separately from permutation. And I think permutation always only needs 1 singleton partition.

So what I envision for the trace is that you have separate lists of commitments for:

• preprocessed
• main
• permutation (single commit)

Then for each RAP matrix, you will have:

• preprocessed submatrix
• partition of main submatrices
• permutation submatrix
  Each submatrix will below to one of the commits in their respective list, and we can record a pointer to which one. But again the partitions are different for each phase.

[shuklaayush]

I changed this from Vec<Domain<SC>> to Domain<SC> since each preprocessed trace is committed separately

[shuklaayush]

This needs to be handled in a better way. Since AIRs from different partitions can refer to the same preprocessed trace, we need to store a global AIR index along with each AIR in a partition

[jonathanpwang]

LGTM