Implications of submitAndAwait on response design

[nedsalk]

The introduction of the submitAndAwait endpoint in #1615 opens up the possibility to modify of what we're returning to the user upon transaction submission.

The current approach of getting transaction results is to use TransactionResponse in a two-step process as follows:

const transferResponse = await wallet.transfer(...);
const result = await transferResponse.waitForResult();

The reason for this is that a transaction sent to the node needs to change states (SubmittedStatus -> SuccessStatus/FailureStatus/SqueezedOutStatus) and the intermediary class TransactionResponse which encapsulates this status change is thus necessary for an user to await the execution of their transaction.

The submitAndAwait subscription, however, does all of that in one call, removing the need for TransactionResponse, primarily because this subscription now returns receipts as well (#1644). Based on that, we could change the response of Provider.sendTransaction depending on the passing of the awaitExecution flag introduced in #1615:

async sendTransaction<AwaitExecution extends boolean,
R = AwaitExecution extends true ? TransactionSummary : TransactionResponse
>(transactionRequestLike: TransactionRequestLike,
{ awaitExecution, estimateTxDependencies = true }: ProviderSendTxParams<AwaitExecution> = {}): Promise<R> {
// implementation
}

This results in the following type inference difference:

In the end, the goal is to communicate the implications of the awaitExecution flag via return types as that is the fastest feedback on what the flag entails.