…ient

With upcoming changes to TS Bindings generation
(stellar/stellar-cli#2283), many more people
will be using `AssembledTransactionOptions`. This currently has the
peculiarity of requiring `contractId`, `rpcUrl`, and `networkPassphrase`
every time you construct an AssembledTransaction. Even if doing so from
a ContractClient, which has already been instantiated with these values!

```
Type `{ publickey: string; }' is missing the following properties from type
'ClientOptions': contractId, networkPassphrase, rpcUrl
```

The root cause, in my opinion, is that `AssembledTransactionOptions`
_flattens in_ `ClientOptions`, rather than accepting a `client`
by reference.

```diff
 export type AssembledTransactionOptions<T = string> = MethodOptions &
-  ClientOptions & {
+  {
+    client: Client;
```

This updates `AssembledTransaction` to instead accept a `client` by
reference, as shown above.

Note that this represents a breaking change! But... only if you were
constructing `AssembledTransaction`s without a `ContractClient` (or TS
Bindings). Which is to say, only if you were doing things _the hard
way._ The _non-standard_ way.

If you use generated TS Bindings, or if you construct a ContractClient
and call its methods directly to create AssembledTransactions,
everything continues to work as it always has. And this code has the
benefit of expressing more clearly what we wanted all along!

If we want to make this backwards-compatible (for the... two? ten?
people out there doing things the hard way), maybe we could do
something like this:

```diff
 export type AssembledTransactionOptions<T = string> = MethodOptions &
-  ClientOptions & {
+  Partial<ClientOptions> & {
+    client: Client;
```

And then, in the AssembledTransaction constructor, we can default each
of these values to the one from `options.client.options`, like the
current change does with `publicKey`.

This is an update to stellar#2283, which changed hard-coded `options` to
`AssembledTransactionOptions`. This was not quite correct, it should be
a `MethodOptions`.

This works together with
stellar/js-stellar-sdk#1293 to finally remove
the need for `@ts-expect-error` lines in our canonical write-method
invocation examples.