Ensure 'interrupt' and 'disconnect' signals are sent before '-gdb-exit'

[Luke-zhang-mchp]

Previous PRs (i.e #292 and #289) do not include an await when sending interrupt/disconnect signals if the debugger is running. This causes the -gdb-exit command to be written and queued before the interrupt/disconnect signals.

An alternate, equivalent solution would look like:

await this.gdb
    .sendCommand('interrupt')
    .then(() => this.gdb.sendCommand('disconnect'));

I did read over #292 (comment) and #292 (comment). I'm not encountering any issues with using await instead of .then. I manually tested this on our IDE with yield operators, and it worked fine. After looking at GDBBackend::sendCommand, there doesn't seem to be any reason await doesn't work. The returned Promise does not resolve until the MI parser receives a response, which guarantees that the command was sent already (that tracks right?):

cdt-gdb-adapter/src/gdb/GDBBackend.ts

Lines 163 to 196 in 44fda62

	public sendCommand<T>(command: string): Promise<T> {
	const token = this.nextToken();
	logger.verbose(`GDB command: ${token} ${command}`);
	return new Promise<T>((resolve, reject) => {
	if (this.out) {
	/* Set error to capture the stack where the request originated,
	not the stack of reading the stream and parsing the message.
	*/
	const failure = new Error();
	this.parser.queueCommand(token, (resultClass, resultData) => {
	switch (resultClass) {
	case 'done':
	case 'running':
	case 'connected':
	case 'exit':
	resolve(resultData);
	break;
	case 'error':
	failure.message = resultData.msg;
	reject(failure);
	break;
	default:
	failure.message = `Unknown response ${resultClass}: ${JSON.stringify(
	resultData
	)}`;
	reject(failure);
	}
	});
	this.out.write(`${token}${command}\n`);
	} else {
	reject(new Error('gdb is not running.'));
	}
	});
	}

If we decide to keep .then, there is still a missing await (as noted above in the equivalent solution).

As you noted in https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/pull/292/files#r1330234785, this does not fix #295, but that issue is causing us some problems too, so I'll spend some time on that as well.

[Luke-zhang-mchp]

On second thought, I'm converting this to draft to address #295 as well.

[jonahgraham]

@Luke-zhang-mchp I appreciate the cleanup that this PR already includes. Do you want to land this PR and then work on #295 as a separate PR?

[Luke-zhang-mchp]

Yeah sure, that works too