Use new soroban-cli token create subcommand

[paulbellamy]

Use the new soroban-cli token create subcommand from: stellar/stellar-cli#166
This meant I had to update the xdr dependency, and some of the code using that.

[paulbellamy]

I think stellar/soroban-examples#123 will fix the build here

[leighmcculloch]

@paulbellamy Now that soroban-examples is updated I've pushed the dep update in 304e48f and make test passes. I'm not sure how to tell the full scope of this PR so I'm going to leave it open for you to merge, but looks like it is good to go.

[leighmcculloch]

I'm taking a quick look if I can remove the dependence on the token example.

[leighmcculloch]

In 78cce35 I've pushed changes that remove the dependence on soroban-token-contract. Instead of using any utilities in that example crate, the project relies entirely on the soroban-token-spec for code that ships when deployed, and in tests it uses the simpler Signature::Invoker to authenticate as a source account.

I've change the way auth works for two reasons:

• It models the type of auth we'll actually be doing with the contract, via Freighter.
• It's the simpler form of auth that most developers will probably use because it is all they need.

@paulbellamy The simpler form of auth works like this:

1. First set the source account to the account id you want to authenticate as.
2. Invoke the contract, telling the contract (that uses soroban-auth) that you're signing as the "Invoker", which is the source account in a direct invocation.

For example:

e.set_source_account(&account_id_you_want_auth_as);
client.approve(&Signature::Invoker, ...)

[leighmcculloch]

@paulbellamy For any scripts that need to invoke the token contract, instead of using ed25519 keys/sigs, you can use the --account option:

Last week I also updated the cli serve subcommand to support account, so this should all be good to go to support any use of accounts in this PR.