Add support for handling failure during deploy

[leighmcculloch]

The host functions for creating new contracts currently do not expose failure. The create_contract_with_constructor host function returns an Address, and not a result that allows for handling the failure of the constructor.

Similar to the issue described in stellar/rs-soroban-sdk#1422, this means a developer cannot handle when a constructor fails.

{
    "export": "e",
    "name": "create_contract_with_constructor",
    "args": [
        {
            "name": "deployer",
            "type": "AddressObject"
        },
        {
            "name": "wasm_hash",
            "type": "BytesObject"
        },
        {
            "name": "salt",
            "type": "BytesObject"
        },
        {
            "name": "constructor_args",
            "type": "VecObject"
        }
    ],
    "return": "AddressObject",
    "docs": "Creates the contract instance on behalf of `deployer`. Created contract must be created from a Wasm that has a constructor. `deployer` must authorize this call via Soroban auth framework, i.e. this calls `deployer.require_auth` with respective arguments. `wasm_hash` must be a hash of the contract code that has already been uploaded on this network. `salt` is used to create a unique contract id. `constructor_args` are forwarded into created contract's constructor (`__constructor`) function. Returns the address of the created contract.",
    "min_supported_protocol": 22
}

https://github.com/stellar/rs-soroban-env/blob/22c8c990d699208c5c9745e506367c03a50d500d/soroban-env-common/env.json#L1493-L1517

I propose we add support for handling failure during deploy. For most host functions there is a way to either handle failure, or to preemptively avoid failure. This is not the case with the create_contract_with_constructor host function.

[dmkozh]

Supporting graceful failures of host functions is generally tricky and risky, as it has to perform rollbacks while bypassing the regular rollback mechanism. I'd generally like to avoid that unless it's absolutely necessary (like try_call for contracts). Is there any particular motivational use case for handling the failure gracefully? This generally doesn't seem like a great idea to me, unless we're trying to support batched contract deployments that also may fail for some reason, which seems really weird (unlike arbitrary contract interactions, deployments are not arbitrary and it's not clear why they should fail).

It's also important to understand what kinds of failures are relevant for graceful handling. If we just don't want to try to re-deploy an existing contract, then that's already possible. But e.g. gracefully rolling back the failure to authorize contract creation seems like a footgun to me.