Fix dynamic proof consumption in the same transaction prover method

[rpanic]

Based on #492

During devnet testing I got this error:
prevs_verified Constraint: (Equal(Add(Add(Constant 0x0000000000000000000000000000000000000000000000000000000000000001)(Scale 0x40000000000000000000000000000000224698FC094CF91B992D30ED00000000(Add(...(Scale 0x40000000000000000000000000000000224698FC094CF91B992D30ED00000000(Var 317928))))))(Constant 0x0000000000000000000000000000000000000000000000000000000000000002))

Turns out there is this bug report that has this error message: o1-labs/o1js#2316
In a nutshell, o1js currently can't currently verify two sideloaded proofs at once when they originate from two different zkprograms.
Now, if we look at the pk circuit that threw this error (TransactionProver), we see that it only consumes DynamicRuntimeProof (s) (we have a variant that consumes one, and a variant that consumes two - purely for optimization, the 2 variant just does the 1 variant twice).
But that should be fine, right? Nope - we have a very dear friend called the zkprogram method limit. To circumvent this limit, what we do in protokit behind the scenes is that once the total sum of runtime methods goes over this limit, we create a multiple programs to split up the methods into buckets and not run into this limit (this is btw why ZkProgrammable.zkProgram() returns an array and why the runtime's verification key is a tree and not a single value).
So during our previous testing, we had a very small runtime which only consisted of one zkprogram and therefore we were fine.
But for kaupang, the runtime is a lot bigger, and will end up generating two zkprograms. Now, when you do two transactions within one settlement period, and those two transactions target runtimes in different programs, the above buggy scenario will occur and lead to this prover bug.

So what is the fix?
As mentioned above, we have two variants of transaction provers. What we can do is for any 2-tuple of runtime proofs, we can check if they originate from the same zkprogram and if not, split them up into two 1-variant transaction prover calls. This is comparatively easy to do luckily.