fix: const enums + isolatedModules emit invalid code

[FauxFaux]

In isolatedModules mode, the compiler does not inline const enums, but also decides not to import them, leaving invalid code that throws a ReferenceError at runtime.

This code:

import { SomeEnum } from './bar';
sink(SomeEnum.VALUE);

..should compile to either:

var { SomeEnum } = require('./bar');
sink(SomeEnum.VALUE);

..or (with const enum inlining):

sink(1 /* VALUE */);

..but actually compiles to:

sink(SomeEnum.VALUE);

..with no imports, which throws a ReferenceError at runtime.

---

The compiler has already realised that the symbol is a referenced const enum, it just doesn't use this information when it comes to deciding whether to emit an import. This commit additionally checks that information, if we are compiling in isolatedModules mode.

---

In my opinion, this is not the correct fix, but it is the simplest. In isolatedModules mode, const enum should probably be a compile error (because there are no benefits and the complexity is high, and, apparently, buggy). If not, the compiler should not be checking whether something is a const enum, and should just be treating it as a regular enum, and checking as if it was?

Fixes #40499.

[ghost]

All CLA requirements met.

[andrewbranch]

Can we add a test for only using the type side of a const enum too? Like

// @isolatedModules: true

// @Filename: /enum.ts
export const enum Foo { Bar }

// @Filename: /index.ts
import { Foo } from "./enum";
function f(foo: Foo) { return; }

[andrewbranch]

I think it’s worth considering adding an error too, but that can be done separately. I see no reason not to take this fix regardless of whether we add an error in the future.

[FauxFaux]

That test is simple enough, and does what I expect (the import, which is only used in type context, is deleted). It doesn't even run the new code. Added.

[andrewbranch]

Thanks @FauxFaux!

[sandersn]

@andrewbranch @sheetalkamat is this ready to go in? From the comment history, it looks like @sheetalkamat 's comments were addressed and @andrewbranch reviewed them, but I want to make sure before merging.

[andrewbranch]

I believe it’s ready, just wanted another team member to review.

[andrewbranch]

A bit of a separate bug, but closely inspecting checkPropertyAccessExpressionOrQualifiedName led me to discover that this import was missing until I added the check for isExportOrExportExpression.

[andrewbranch]

Thanks @FauxFaux! Sorry this ended up being more complicated than you bargained for 😅