Add the recommended eslint plugins for TypeScript

[iflan]

This adds both the recommended TypeScript checks, plus the recommended TypeScript checks that require type checking. This latter addition means that eslint essentially has to compile all of the TypeScript in the project, causing it to be slower. This isn't much of a problem in VS Code because there's a lot of caching being done, but it's clearly slower when run on the commandline.

All of the errors are either fixed or suppressed. Some errors are suppressed because fixing them would be too laborious for the little value gained. Others are caused by some overly-zealous matching that requires a config refactoring to fix.

[iflan]

⚠️ I do not like some of the recommended settings:

• @typescript-eslint/no-inferrable-types: I much prefer to see everything have an explicit type in general, but particularly where some fields have defaults and others do not.
• @typescript-eslint/no-non-null-assertion: I don't mind this when the entire file assumes that certain elements will be in the DOM, like ui/apple2.ts.
• @typescript-eslint/no-empty-interface: I think that having empty interfaces is fine because it indicates that there's an anticipated structure that just doesn't have any fields yet. All of the workarounds seem clumsy and obfuscate the intent more than anything else. Likewise, interfaces that are equivalent to their supertype are equally useful to say, "It's like that thing, but not exactly that thing."

For all of these settings, I would be happy to revert the changes and disable the rule. If we think that the rule is fine in general, but not for a subset of files, that's fine with me, too. (For example, the no-non-null-assertion rule could be turned off for the /ui/ package.) If we do that, I'll do a general refactor of the eslint settings to make it easier to change in the future.

[whscullin]

I have a bit of deja vu about maybe having tried to turn this on before and having mixed feelings. I tend to agree with you, I like explicit types, and while I kind of get the rational for "no empty interfaces" I do like laying out structure with them. Also, an empty interface is guarding against stray assignments in a way that Record does not. The no non-null assertions are also frustrating because the code written without them either becomes a sea of optional chaining operators or extremely verbose. However, as we transition away from direct DOM manipulation that becomes less of an issue. I think turning it off for the /ui/ directory would make sense.

[iflan]

This is obsolete with #121 merged.