Add cargo contract upgrade command

[ascjones]

cargo contract upgrade $proxy-address $implementation-address --suri $account

Upgradeability is a well-known feature in the blockchain ecosystem: it allows a contract implementation to be modified, fixed, and improved without the need of deploying the new contract in a new address. Using a proxy pattern to implement upgradeability has its pros and cons (some are mentioned below).

This command should allow developers to upgrade a given proxy $proxy-address to a new implementation $implementation-address . To mitigate problems, this contract should check that:

• The implementation's storage layout has not been corrupted. For this, it is necessary to persist the storage layout of the previous implementation, and to compare its storage layout against the new implementation's storage layout. More information about typical storage layout collisions can be found here.
• The functions defined in the proxy contract and the ones defined in the implementation contract do not share any function selector, to avoid function selector collisions.
• There are no shared keys between the proxy and the implementation: in other words, all the variables defined in the proxy contract should not collide with the variables defined in the implementation contract.

[HCastano]

As a pre-req for this, we'll probably want the underlying implementation of #101 done

[HCastano]

We may also want to split this issue up into two subcommands:

• cargo contract upgrade proxy
• cargo contract upgrade set_code_hash

The proxy command would need to:

• Check for storage collisions/corruption in the new Logic contract
• Check for selector clashes between Proxy and new Logic contract

The set_code_hash command would need t:

• Check for storage collisions/corruption in the new Logic contract
• Don't think function clashing would matter here since we're able to swap the contract
  entirely

[ascjones]

See https://github.com/OpenZeppelin/openzeppelin-upgrades/tree/master/packages/core/src/validate for inspiration

[SkymanOne]

I believe we need to address use-ink/ink#1388 first

[ascjones]

I believe we need to address paritytech/ink#1388 first

This could be relevant: use-ink/ink#1909

[ascjones]

Linking use-ink/ink#1981, which would be useful for migration