build: prepare for TypeScript 3.9 - #36855

…e program

- Fix several compilation errors
- Update @microsoft/api-extractor to be compatible with TypeScript 3.9

The `NodeJSFileSystem.isCaseSensitive()` method was computing
completely the opposite value for its result.

Also the `NgtscCompilerHost.getCanonicalFileName()` method was
not actually calling `useCaseSensitiveFileNames()` so it was always
assuming that the filenames were case sensitive and not actually
canonicalizing them. Instead just returning the original.

Once these two bugs were fixed, a number of issues with the rest of the
handling of case-insensitive files in compiler-cli and tests were uncovered.

This commit also fixes these issues. Here are some further notes:

The TS compiler canonicalizes filenames internally for lookups etc. So
if we are also doing file lookups we need to use the same canonicalized
forms. This is achieved by injecting the `ts.CompilerHost` where needed
and calling `getCanonicalFileName()`. For example, when computing the
`rootDirs` in the `LogicalFileSystem`.

Some tests were checking that particular source files were being exposed
by comparing the `ts.SourceFile.fileName` property with some non-canonical
filename. In some cases this would fail. Instead these comparisons are
achieved by directly comparing the SourceFile objects, if known, or getting
the SourceFile object from a non-canonical filename from the program, by
calling `program.getSourceFile(nonCanonicalFileName)`.

The `MockFileSystemWindows` class was not considering lower case drive names
when computing if a path is rooted (i.e. absolute).

The `NodeJSFileSystem.isCaseSensitive()` method was relying upon its `exists()`
method. But this itself relies upon the `isCaseSensitive()` to determine
if a file exists. So there was an infinite recursion. This is solved by
actually using the underlying real `fs.existsSync` to compute whether the
file system is case sensitive.

…ctly