Move byte-checks of Keccak to Syscall side and include lookups for length bytes

[querolita]

This PR aims at constraining the byte-ness of the length prefix read from the oracle in the first few bytes before reading the actual preimage bytes.

In order to simplify the Keccak lookups, I also moved the actual preimage byte-checks from the Keccak side to the MIPS side (this means 4 lookups per SyscallReadPreimage row instead of 200 lookups per absorb row).

Together with the length bytes checks, this means 8 lookups derived from the request_preimage_write() function.

I made this PR because I think it is good for soundness, but I am sure there's a better way to do it. In particular, it's absurd to perform 8 lookups when you know at most you read 4 bytes. We should think of a better way to "merge" length and preimage bytes in the same vector instead of having one for each.

I am unsure if the 8 bytes of the preimage are always read in two rows of 4 bytes each, or if instead it could combine things like: first call 3 bytes, second call 3 bytes, third call 2 bytes of length and 2 bytes of preimage. Of course, if it always read 4 and 4, then the length bytes and preimage bytes would never have to "share" the vector, as they would always live in separate rows. And then removing the extra 4 lookups is just trivial.

After checking unit tests, the 8 bytes of length can be read in combination with preimage bytes, as it depends on the address (whether or not it is aligned).

Nonetheless, if that is not the case, we might want to think of smarter ways to combine the vector in a way that is compatible with the preimage chunk computation and the rest of preimage constraints.

[querolita]

Checked demo, this does not halt the VM and the SyscallReadPreimage constraints hold.

[dannywillems]

I'm waiting for 2274 and 2305 to be merged to fix conflicts and continue reviewing. Taking care of solving conflicts.

[dannywillems]

Solving conflicts now.