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.