Beacon-set deployers: resolve BEACON_INITIAL_OWNER from the address registry so rotating it stops moving the Zoltu address

[thedavidmeister]

The problem

StoxOffchainAssetReceiptVaultBeaconSetDeployer is Zoltu-deployed and hardcodes
its config so the constructor is parameterless. Its NatSpec states the motive:

a parameterless constructor that hardcodes the config from
LibProdDeployCurrent. This makes the contract Zoltu-deployable.

That config includes initialOwner: LibProdDeployCurrent.BEACON_INITIAL_OWNER.

So the owner is in the deployer's creation code, and its Zoltu address is a
function of it. Change BEACON_INITIAL_OWNER and the deployer's address moves,
along with its pinned ..._CANDIDATE address and codehash in LibProdDeployV4.

The other side of the trap: rain.vats constructs
new UpgradeableBeacon(impl, config.initialOwner), so every beacon this deployer
creates is owned by that hardcoded address. Retiring the owner strands them;
changing it to avoid stranding moves the deployer.

StoxWrappedTokenVaultBeaconSetDeployer should be checked for the same shape.

Proposed

Resolve initialOwner from the address registry (rainlanguage/rain.deploy#25)
by name, in the constructor. It stays parameterless so Zoltu still works, and the
creation code then carries only the registry address and a name — both stable —
so rotating the beacon owner no longer moves the deployer.

initialReceiptImplementation and initialOffchainAssetReceiptVaultImplementation
stay hardcoded. A different implementation genuinely is a different deployer, so
those belong in the derivation.

Blocked on

rainlanguage/rain.deploy#25 — the registry, its interface and lib.

Note

Token and vault instances are unaffected: both beacon-set deployers create them
with new BeaconProxy(...), which is CREATE, so those addresses are
nonce-ordered and were never deterministic.