Investigate divergence between local and CI linter.

[grypez]

Linting passes on mine, too. This complaint appears to be CI-specific. Relevant bug here. I haven't investigated why the behavior diverges between local and CI.

The cause of the issue is that CommandLike<CommandMethod.Evaluate, string> appears in both Command and CommandReply, so the union type Command | CommandReply after substitution

| ...
| CommandLike<CommandMethod.Evaluate, string>
| ...
| CommandLike<CommandMethod.Evaluate, string>
| ...

appears to the CI-linter as a redundancy.

Given that these are called union types, I find it hard to be sympathetic to the complaint. We could alleviate it following the guidelines for discriminating union types by adding a field like reply: boolean to Command and CommandReply and flipping the switch between them. We should align the CI behavior with the local behavior in any case.

Originally posted by @grypez in #94 (comment)

[rekmarks]

See #151 for the latest verification that this is still a problem. It fails with:

Promises must be awaited, end with a call to .catch, end with a call to .then with a rejection handler or be explicitly marked as ignored with the `void` operator. A rejection handler that is not a function will be ignored  @typescript-eslint/no-floating-promises

For the line:

main().catch(logger.error);

Where the type of logger.error is:

(property) error: {
    (...data: any[]): void;
    (message?: any, ...optionalParams: any[]): void;
}

[rekmarks]

We found the problem (from: #151 (comment))

Aha, @typescript-eslint is unhappy with the overloaded interface type for console.error, which logger.error inherits. We should probably write our own types for the logger that eschew interfaces.

[rekmarks]

This is a different issue from the one originally described in this issue, which we're no longer suffering from. I'll create a new one for the specific problem of #151.