Remove dependency on variants in proposal builders

[mhofman]

What is the Problem Being Solved?

We've started to heavily rely on parametrized proposal builders, in particular accepting a variant for the deployed network, to encode chain specific config. This makes deploying and testing upgrades very difficult and error prone. While #10837 proposes a change to stop relying on the upgrade name to trigger the variant logic, I'd like to stop relying on variants altogether.

Description of the Design

The proposal should be able to read current chain parameters if it's simply restoring those. In the case where new / updated parameters need to be provided during the upgrade, we should rely on explicit parameters as part of the upgradeInfo of the upgrade proposal. Currently that can be done using a set of proposals info including arguments.

Security Considerations

None

Scaling Considerations

Avoid hard coding chain specific logic in software that should be generic.

Test Plan

a3p integration test

Upgrade Considerations

Make upgrade paths more generic.

[mhofman]

In #10947 (comment), @Chris-Hibbert mentions that FeeDistributor is not a governed contract so it has no way to store or dynamically update parameters.

There are 2 cases worth considering:

• How should a chain software upgrade be able to upgrade the bundle of such a contract without requiring the chain specific config captured in code.
• How can a test like a3p "override" the recorded parameters during the upgrade for testing purposes.

I suspect that what the first point implies is that there is an upgrade API to update the vat's bundle but carry over the current params that SwingSet would have saved (#8947).

The second point likely implies that the test part of a3p should be able to explicitly perform another contract upgrade (using the current bundle), but passing new parameters for the test, and making sure these test parameters are not persisted in the base image. This can likely take the form of running a "core proposal" as a governance action (#8908)