Refactor SetTableAddrType

[naure]

While adding memory and PI features, there has been some leakage of frontend concepts into the backend, which should only know about math, not VMs.

Some pointer: SetTableAddrType::DynamicAddr

This could be refactored into a new type of polynomial type, similar to Constant, Fixed, etc. Let’s say Linear.
Then the circuits can use Linear columns to do for example address ranges.

Another problem is that this table specification is needed during circuit "construction", but it belongs more logically and conveniently to the fixed table generation phase. I don’t know how to fix that one yet, though. (already solved by CircuitBuilder.params)

[naure]

More precision here:

In CircuitBuilder, the methods lk_table_record, r_table_record, and w_table_record take an argument table_len or table_spec.len. That information makes it to VerifierKey.cs and is used to determine numbers of rounds.

My claim is that these length could move either some new property of VerifierKey or Proof. It could work the same way as the non-table variants: lk_record, read_record, write_record, or something like num_instances.

[naure]

Alternatively, the lengths could stay in CircuitBuilder, but then let the API accept parameters by value like in #587.

[hero78119]

I raise another issue which is from backend perspective #654
which also related to probably introduce a new type of polynomial to hold meta info of SetTableAddrType.

[naure]

Closing in favor of the more precise #654.