Handle "TODO" comment in `new_llzk_module()`

[tim-hoffman]

// TODO: This approach does not currently handle ArrayInLine or Call expressions that can be
// used as parameters to the main component. The Call case could be handled by finding the
// target function and evaluating it statically. The ArrayInLine (i.e. a literal array like
// `[9,3,1]`) however may require generating an additional wrapper struct that can construct
// the array and pass it to the main component. Alternatively, put the array in a global const
// and then generate the main component with one less template parameter and read the global.

Reproduced by the following:
circom/tests/arrays/array_copy1_loop.circom
circom/tests/arrays/array_copy1_vec.circom
circom/tests/arrays/array_copy4_vec.circom

Fails with the following error:
main component parameter {i} is not a positive constant

[tim-hoffman]

I think the key will be to first solve the issues in these tests:

• circom/tests/misc/main_param_call_manual.circom
• circom/tests/misc/main_param_array_manual.circom

and then generate code equivalent to them for these:

• circom/tests/misc/main_param_array.circom
• circom/tests/misc/main_param_call.circom

[0xddom]

Regarding main_param_array_manual: While creating poly.expr ops, what types can they have? If we can have them yield values of !array.type<...> we can simply wrap the inline array expression with a poly.expr and refer it by name the same way we do for literal numbers too large for i64.

We'll then have to handle somehow what types to put in the @params record in the subcomponent's pod (when applicable) since right now it's assumed that all of them are !felt.type. Lastly, for defining the template parameter containing an array we can use a N-dimensional affine identity map where N is the size of the array.

[tim-hoffman]

LLZK currently allows only "integral, felt, or typevar type" as operand to poly.yield because it was originally intended for array dimension sizes. We can consider making the change you suggest. We may want to add additional type checking on top of the symbol existence verification step to ensure it's a scalar value when used as array dimension, etc.

We do have a couple of benchmarks that are failing because they already try to yield array.type from poly.expr so it seems there's another scenario that can benefit from this:
libs/zksolid-libs/circomlib/test/circuits/escalarmul_min_test.circom
libs/zksolid-libs/circomlib/test/circuits/escalarmul_test_min.circom