Lint to ensure CompilerOptions and options in commandLineParser are synchronized

[weswigham]

A number of our @internal options were missing from our option definitions in commandLineParser.ts, which in turn causes us to elide them from telemetry, even though we may forcibly set them in the language service.

This PR adds a lint rule that compares the CompilerOptions interface and the option definitions in commandLineParser.ts and ensures their state is synchronized. It also adds an internal field to command line option definitions whose only purpose is tracking which options are @internal annotated. This is currently unused but should be a good runtime indicator to anyone looking over our option definitions which ones aren't meant to be used publicly. This field is also synchronized by the lint.

[weswigham]

The LS sets allowNonTsExtensions for any project with js and any inferred project forcibly - this wasn't reflected in telemetry (and all these baselines), since without an options declaration, the serializer couldn't serialize the option.

[weswigham]

This PR no longer has any functional changes, and instead just has a lint rule to check that commandLineParser.ts and the CompilerOptions interface in types.ts are synchronized. We could do this at compile-time with type arithmetic (though not the @internal sync bit), but it'd require as consting most of the option definitions and collections in commandLineParser.ts, which seems a little heavyweight when we can't easily outright derive CompilerOptions from the option definitions (and so would still need quite a bit of duplication) because there's a collection of 3 calculated fields on CompilerOptions we use to smuggle path/origin information for the options around (which this lint rule exempts from the sync check).

Running it exposed a couple more internal compiler options we didn't have option definitions for that I didn't already know about.

[jakebailey]

If an option is marked internal, can extraValidation always just issue this wherever that func is called? Or is that too annoying? Seems like this is copy/pasted a bunch, but I guess not for anything outside this block?

[jakebailey]

It feels a little weird to enforce this via a lint rule, but I guess if it's too annoying to do statically...

[sheetalkamat]

we have testcase

TypeScript/src/testRunner/unittests/config/commandLineParsing.ts

Line 252 in cd566ba

it("should have affectsBuildInfo true for every option with affectsSemanticDiagnostics", () => {

which checks if all affectsSemanticDiagnostics are marked as affectsBuildInfo as well. May be some test case like that would be better than lint rule

[weswigham]

we have testcase

TypeScript/src/testRunner/unittests/config/commandLineParsing.ts

Line 252 in cd566ba

it("should have affectsBuildInfo true for every option with affectsSemanticDiagnostics", () => {
which checks if all affectsSemanticDiagnostics are marked as affectsBuildInfo as well. May be some test case like that would be better than lint rule

The perk of the lint rule is that it has an autofixer (that adds the missing declarations to whichever side of the pair of declarations is missing one) - not so for a test.