[Experiment] Batch inversions of registers accesses done before folding

[querolita]

This is an exploratory PR trying to fix #2040 , where inverses involved in register accesses were substituted with a dummy term (making the constraints unsatisfiable).

Here, I am proposing a new kind of Column called InverseState with at most 9 elements which will keep track of the values that were supposed to be inverted throughout the step execution. Instead of doing this per-step, we are batching these inversions at the end, before folding the witness. At that time, the witness gets mapped from u64's to actual Fp elements, and the columns corresponding to inverses are mapped to their inverse value in the field with a single batch inversion for the whole 9 columns.

Given that most instructions won't use the 9 columns for inversions, these columns are set to 1 by default (reason why when we reset the self.inverse_state after every step, we initialize them with 1's instead of 0's as for the scratch state).

This is just an idea, so please feel free to point out any possible detail I might be missing. I am pointing this out because at first I thought it would be a very complicated change, but the diff right now is not that huge (so I am afraid I might be forgetting about something important).

[dannywillems]

Idea: not using batch_inverse from arkworks, but implementing the batch inversion ourself, ignoring zero

acc = 1
for i, x in witness.iter().enumerate():
  acc *= x if x != 0
acc_inv = acc^-1
for (i, x) in witness_backwards.iter().enumerate():
  inverse_state[i] = acc_inv * x if x!= 0 else 0

[querolita]

Idea from Matthew after our 1:1 to avoid costly u64->Fp transformations:

Perhaps we don't need the Montgomery representation until the very end of the folding, and in between we can instead work with BigUint. Even compute the batch inverses as a BigUint modulo the field size.

[querolita]

I made this a draft because performance is still not as fast as desired (in my machine, Matthew's idea runs at 1.3 Mhz, but this one is about 5 times slower). I believe it is the castings from u64 to F what is causing it. Will go back to it in May after finishing the main goal for part 1.

[querolita]

Idea: not using batch_inverse from arkworks, but implementing the batch inversion ourself, ignoring zero

@dannywillems actually the batch_inverse from arkworks already ignores zeros, so that's not a problem anymore