CLI: Separate sandbox command into a separate top-level command

[leighmcculloch]

Looking at how the deploy command is shaping up, and how the two modes of operation are so different, I think we should separate sandbox logic into a sandbox sub-command.

This are the options for the deploy command being added in #152.

soroban-cli deploy

        --wasm <WASM>
            WASM file to deploy

        --id <CONTRACT_ID>
            Contract ID to deploy to (if using the sandbox)

        --ledger-file <LEDGER_FILE>
            File to persist ledger state (if using the sandbox) [default: .soroban/ledger.json]

        --rpc-server-url <RPC_SERVER_URL>
            RPC server endpoint

        --private-strkey <PRIVATE_STRKEY>
            Private key to sign the transaction sent to the rpc server

        --salt <SALT>
            Salt to use when creating contract sent to the rpc server

        --network-passphrase <NETWORK_PASSPHRASE>
            Network passphrase to sign the transaction sent to the rpc server

The goal would be to split that in half like:

soroban-cli sandbox deploy

        --wasm <WASM>
            WASM file to deploy

        --id <CONTRACT_ID>
            Contract ID to deploy to

        --ledger-file <LEDGER_FILE>
            File to persist ledger state [default: .soroban/ledger.json]

soroban-cli deploy

        --wasm <WASM>
            WASM file to deploy

        --rpc-server-url <RPC_SERVER_URL>
            RPC server endpoint

        --private-strkey <PRIVATE_STRKEY>
            Private key to sign the transaction sent to the rpc server

        --salt <SALT>
            Salt to use when creating contract sent to the rpc server

        --network-passphrase <NETWORK_PASSPHRASE>
            Network passphrase to sign the transaction sent to the rpc server

The flow of use would be like this:

To deploy to sandbox, or read from sandbox, etc:

soroban-cli sandbox deploy ...
soroban-cli sandbox read ...
soroban-cli sandbox invoke ...

To deploy to network, etc:

soroban-cli deploy ...

This design is evident in one other tools we've seen:

• The move-cli has its sandbox commands under a sandbox subcommand like this. e.g.: https://github.com/move-language/move/blob/74f8741e9d3e9e893149a7bd2fab04f8ed1c2037/language/tools/move-cli/README.md

Other tools I looked at take different approaches:

• forge (https://book.getfoundry.sh/reference/forge/forge-create) – doesn't really have a way to run or deploy contracts locally outside of their test framework afaict, so difficult to compare.
• hardhat (https://hardhat.org/hardhat-runner/docs/guides/deploying) – does have a local sandbox environment and interacting with it is much more similar to a real network, although this is easier for them to do because actions like deployment are scripted rather than command lined.

Alternatives are:

1. Keep things as they are, see how far we can get.
2. Change the sandbox commands to identically mimic the real commands, but this comes at a cost of making the initial learning curve steeper when first experimenting with Soroban contracts.
3. Possibly others, any ideas?

Thoughts @tomerweller @paulbellamy @sisuresh @2opremio @tsachiherman ?

[leighmcculloch]

Exploring #173 as an alternative.