Carry along an updateable universal_prover during synthesis and execution

[vicsn]

Motivation

Howard noticed that in the previous PR certain tests would end up loading the SRS twice: first during synthesis and then during execution. To avoid this, this PR proposes carrying around the trimmed SRS (UniversalProver::committer_key ) and updating it as needed.

Notes:

• trim(...) is renamed update(...), to reflect that we can shrink or grow the trimmed SRS as needed. The current implementation of this update function is not atomic. If it fails halfway through, we might have an inconsistent UniversalProver. It seems ok to me to always expect that we first need to succesfully update before creating a new proof. Though this might not play nicely with parallelization.
• To avoid generating the universalProver every time we synthesizes proving keys ánd every time we prove and execution, I turned the UniversalProver into a global object in Process. Individual threads can acquire a write lock to use it for their specific proof. Depending on the context, this might incur a significant slowdown if we want to synthesize and prove in parallel. However, I reckon parallel proving within a single Process is not a usecase we're aiming to support at the moment anyway.
• We take one power of two less for the SRS, it appeared that it was superfluous.
• For a large circuit (say, 2^25), reduce_pk_size_{2,3} reduce proving time by ~8% on a 16 CPU, 128GB RAM machine.

Test Plan

I manually ran test_multiple_deployments_and_multiple_executions to see if we load the expected amount of powers.

[Lanckneht]

gm