Closes AP-727, AP-791: EndowmentMultiSig proxy admin update & update EndowmentMultiSigFactory's registrar on new Registrar deployment

[0xNeshi]

Explanation of the solution

• Noticed we have a missing EndowmentMultiSigFactory's registrar update on new Registrar deployment - addressed this
• EndowmentMultiSig proxy admin update on calling EndowmentMultiSigFactory.updateProxyAdmin
• smaller refactors to EndowmentMultiSigFactory

Instructions on making this work

• run yarn or yarn install to install npm dependencies

[linear]

AP-791 Update EndowmentMultiSigFactory's registrar address when deploying a new Registrar contract with task `deploy:Registrar`

• Add a function EndowmentMultiSigFactory.updateRegistrar that updates the registrar address
• Call the function when running task deploy:Registrar

AP-727 Update all existing EndowmentMultiSig proxy admins on calling `EndowmentMultiSigFactory.updateProxyAdmin`

https://github.com/AngelProtocolFinance/evm-smart-contracts/blob/master/contracts/multisigs/endowment-multisig/EndowmentMultiSigFactory.sol#L74

[0xNeshi]

Need this to be able to update all of the instantiations' proxy admins

[0xNeshi]

Constructor behavior was the same as if these functions were called one-by-one

[0xNeshi]

Updated the purpose of this task to focus on changing proxy admin for a single proxy contract.
See changeProxyAdminForAll task for a task doing this for all proxy contracts

[stevieraykatz]

Approved tho see my longer comments in the Solidity Crew chat about:

1. Whether this needs to be a proxy
2. Generally how we approach deciding what's worth changing for prod-deployed contracts

[0xNeshi]

@stevieraykatz let me know which changes you think need to be reverted and will do on Monday

[stevieraykatz]

@stevieraykatz let me know which changes you think need to be reverted and will do on Monday

re: EndowmentMultiSigFactory
It looks like we've already deployed a number of endowments using the existing version of the Factory contract. Do we need this state for any reason? We'd "lose" it in this upgrade. If we need this state at all then this is a bigger conversation and we should put a hold on this PR until we determine what we need.

If we don't need this state, then I think all of the changes to EndowmentMultiSigFactory are good AND we should deploy it behind a proxy so that it's easier to upgrade in the future if we need to.

re: import removal
We can keep this change but shouldn't proactively upgrade affected contracts. It makes no functional change to the contracts affected so having both versions in the wild (the outcome of leaving this change in) is negligible.

re: errors removal
If we weren't ever emitting this error in any contracts that use IterableMappingAddr then the logic to leave this change in is the same as the unused import. We don't need to proactively upgrade inheriting contracts and it won't cause any "out of sync" issues between contracts expecting different versions.

[0xNeshi]

re #377 (comment):

re: import removal
...
re: errors removal

Will add those back then