Implement CAP-58 (constructor support)

[dmkozh]

What

The implementation itself is fairly simple (thanks to not needing to support v21 semantics) and follows the CAP-58. It only has a few caveats:

• Pre-v22 protocol Wasms are treated as if they don't have a constructor (they shouldn't have it anyway, but just in case they do we ignore it in order to not break the contract semantics). Thus we don't need to even try calling constructor for them
• We try to call constructor for all v22+ contracts, so we charge for VM instantiation, which increases the creation cost to some degree. I'm not sure if we can discount calling non-existent functions; if we find that necessary, we can still improve this before the protocol release.

Bulk of this change is tests, and testing is really not trivial as we want to cover a set product of several different options:

• p21 vs p22 contracts
• v1 vs v2 host function
• Constructor return values and errors
• constructor arguments present/not present/'default' constructor
• auth for constructor itself and inside the constructor
• deployer support
• invoker auth support
• custom account support

To make things worse, a contract may only have a single constructor, so this needed a lot of new test Wasms.

Why

See CAP-58 motivation.

Known limitations

I'm sure I haven't covered every possible combination of parameters in tests, but at least tried to have some basic coverage for most of the cases and most obvious combinations.

[anupsdf]

If a pre-v22 contract gets its wasm updated in v22+ protocol with update_current_contract_wasm host fn call and the new wasm has a constructor, we will not be calling the constructor right?

[anupsdf]

If a pre-v22 contract gets its wasm updated in v22+ protocol with update_current_contract_wasm host fn call and the new wasm has a constructor, we will not be calling the constructor right?

Nevermind, I see this mentioned in the CAP, When the contract has its code updated it is not considered created and thus constructor won't be called.