Rebased logUp implementation

[LindaGuiga]

This PR corresponds to @wborgeaud's implementation of logUp, rebased on the new main.
There are a few changes from the original implementation, as this PR takes into account @ulrich-haboeck's comments on the original PR. The changes are:

• we use CTL challenges for logUp (instead of generating new challenges)
• we remove one helper column by changing the Z polynomial verification, as per the suggestions
• additional asserts: sanity checks in ArithmeticStark and BytePackingStark to ensure the value is below the maximal value, and: total_num_logUp_entries < char(F)
• changes in the comments following the suggestions
• a change in function names: eval_lookups_checks -> eval_packed_lookups_generic and eval_lookups_checks_circuit -> eval_ext_lookups_circuit, to follow suggestions.

A couple of comments are not addressed here:

• "Also asked at a different place: Why are local and next values vectors, whereas for StarkEvaluationVars they are slices." => I believe the reason why LookupCheckVars have Vecs while StarkEvaluationVars have slices is that in the Lookup case, we do not know the size of the local and next values in advance.
• "I might miss something here, but why do we want to have the values of other auxiliary polys (besides the running sums/products of the lookups) at the shifted value g*x (i.e. the point corresponding to the next step in time)? Is that for convenience, as we put all the auxiliary polys under a single Merkle cap?"
• "Just a side question: Do we ever want to have zk for a STARK?"

[LindaGuiga]

We removed the where clauses related to CpuStark columns: [(); CpuStark::<F, D>::COLUMNS], as it seemed to fix the compiler errors. I have no idea why this "fix" works (or why the issue appeared in the first place). Does anyone (for example @dlubarov?) have any insight in this regard?

[Nashtare]

We removed the where clauses related to CpuStark columns: [(); CpuStark::<F, D>::COLUMNS], as it seemed to fix the compiler errors. I have no idea why this "fix" works (or why the issue appeared in the first place). Does anyone (for example @dlubarov?) have any insight in this regard?

@LindaGuiga @dlubarov
I couldn't figure out why the error message was mixing ArithmeticStark and CpuStark, so I spent more time on this weird issue with the where clauses.
After some local experimentations I realized that pulling the latest main changes had removed this error. I can't get why the previous revision was failing, though it seems more likely to be a bug from the unstable feature than anything else.

[wborgeaud]

Looks great, thanks!