improve batching sumcheck concurrency to dominate by max num var polynomial

[hero78119]

Previously (devirgo) sumcheck concurrency when batching with different number of variables, are dominated by the smallest num_vars. The reason is because for the num_var < log_2(threads) we can NOT divide it's evaluation into #thread region.

This PR addressed the issue by introducing a extra meta information for each polynomial, so we are able to differentiate those small poly and calculate its multiplicity correctly

Design rationale

For some extreme small polynomial (num_var << log(threads)), we define a new PolyType::Phase2Only to differentiate them. These type of small polynomial will be handle by main_worker only during phase 1 sumcheck. And when moving to phase2 sumcheck, those small poly will expand the size to match with all. This cost is negligible giving phase2 only need to run on #thread evaluations.

benchmark

There is no different with before/after change, since we dont have batch sumcheck with different num_vars in critical path, which meet expected

e2e Fibonacci 2^20

fibonacci_max_steps_1048576/prove_fibonacci/fibonacci_max_steps_1048576
                        time:   [2.8894 s 2.9028 s 2.9180 s]
                        change: [+0.1414% +0.8059% +1.5474%] (p = 0.05 < 0.05)
                        Change within noise threshold.

e2e Fibonacci 2^21

fibonacci_max_steps_2097152/prove_fibonacci/fibonacci_max_steps_2097152
                        time:   [5.1785 s 5.2061 s 5.2291 s]
                        change: [+0.7256% +1.3249% +1.9085%] (p = 0.00 < 0.05)
                        Change within noise threshold.

e2e Fibonacci 2^22

fibonacci_max_steps_4194304/prove_fibonacci/fibonacci_max_steps_4194304
                        time:   [10.308 s 10.330 s 10.353 s]
                        change: [+0.9437% +1.2216% +1.4899%] (p = 0.00 < 0.05)
                        Change within noise threshold.

[spherel]

LGTM!