Extract bulk of TS Bindings functionality to ContractClient in stellar-sdk

[chadoh]

What problem does your feature solve?

1. Move bulk of TS code into a TS codebase, so it can be maintained, improved, and reviewed by TS experts. We currently have a large amount of TS in a Rust codebase
2. Support at-runtime / dynamic functionality. Most of the functionality here does not need any build-time dependencies, which means we can have the same specialized-for-a-contract AssembledTransaction behavior in generic JS and in-browser contexts that we currently limit to people's editors at build time.
3. Rather than copy-pasting huge chunks of TS from a CLI to an NPM module over and over, we can move that TS to a dependency. The TS Bindings can then be simplified to only the type information, which can rely on that dependency rather than copy-pasting.

What would you like to see?

This work was already started in stellar-sdk and now lives on the bindings branch there. The idea:

• Given a contract spec, dynamically generate a ContractClient for it
• This new ContractClient is basically the Contract class export from the current TS Bindings
• For each method in the contract, the generated ContractClient exports a JS-ified method (so check_balance becomes checkBalance) which will construct a transaction, wrap it in an AssembledTransaction, simulate the transaction, and return it.
• All the types and logic associated with AssembledTransaction can now move to stellar-sdk
• TS Bindings can then be simplified to only fetch a contract's XDR spec, generate one of these ContractClients, and add TS types to them, which cannot be generated at runtime.

What alternatives are there?

Continue doing this as we do now.

[janewang]

• Tests are failing
• Code splitting in stellar SDK