Setup security mechanism: TSS updater, pauser, etc..

[lumtis]

V1 contract has some security mechanism in case of emergency: TSS updater, pauser, etc...
Some mechanisms should be ported to v2, some eventually not or modified (example TSS shouldn't be able to set cap for ERC20Custody)

• Check the current security mechanism in v1 contract
• Port v1 mechanism, write a spec and make eventual modification for v2
• Implement mechanism in V2 contract

[fbac]

Discussion related to TSSUpdater: #247 (comment)

TL;DR design a proxy pattern mechanism so the security modifiers related to onlyTSS(), onlyAssetHandler() are defined in external contracts, that way:

• The TSS address lives in a contract. For every new TSS Address we'd deploy a new contract.
• Security functionalities implement a proxy pattern so they can be upgraded whenever the "addresses" contract changes.
• system contracts (Gateway, Custody, etc) shouldn't know anything about addresses.

[lumtis]

To take in consideration: change OnlyTSS to TSSUpdater or something similar for SetCustody and SetConnector for EVM Gateway.

OnlyTSS would require develop a specific message on the protocol to let the TSS sign such message, which is less flexible solution for the time being./ The entity that has the upgrade contract privilege can already overwrite the message implementation, it makes sense that this same entity has the authorization to call the above functions.

Things should be same for similar other logic. TSS should only be used for core CCTX logic, admin function should be authorized by the contract admin (which could be transferred to the TSS in the future)