refactor: plonk.Setup takes kzg srs in canonical and lagrange form

[gbotrel]

This PR changes the signature of plonk.Setup(...) and adds an additional parameter; the kzg.SRS in Lagrange form.

In production, this can be computed using gnark-crypto ToLagrangeG1 helper from a canonical SRS.

For test purposes when we know the tau used for generating the canonical srs, we can take a quicker path (see test/unsafekzg package which offers a convenient api to generate and cache in memory / on disk srs for test purposes).

[ThomasPiellard]

Couldn't we use an option to pass the kzg SRS in Lagrange form to the Setup ? When using unsafekzg.NewSRS it's ok since the Lagrange srs is generated quickly anyway, but if one uses a production ready srs (in canonical) for testing purpose one might not want to generate the corresponding lagrange srs each time the size of the circuit changes. Just a suggestion

[ivokub]

Looks good. A few comments though but they are not blocking.

[ivokub]

Imo on thing we could consider in the future is to have a lazy SRS. We can store it on disk and only when we actually we read it to memory (using mmap). Or more better, because the key is very structured we can have method a la Get(index int) and then we read exactly from the location we need by computing the exact byte location on disk.

[gbotrel]

Couldn't we use an option to pass the kzg SRS in Lagrange form to the Setup ? When using unsafekzg.NewSRS it's ok since the Lagrange srs is generated quickly anyway, but if one uses a production ready srs (in canonical) for testing purpose one might not want to generate the corresponding lagrange srs each time the size of the circuit changes. Just a suggestion

@ThomasPiellard yes good idea but it changes the PlonK prover code too a bit so will do it in another PR