Move to file: fix detection of references to globals that shouldn't be moved

[andrewbranch]

Fixes #59799
Fixes #60408
Closes #60173
Closes #60410

isGlobalType was a red herring; it was implemented incorrectly but it never mattered if something was a global type. What we actually care about is whether the thing we’re moving was merging with declarations in other files. If we check that after ruling out that it was in an import, then it must be a global, and if the thing has a global definition in another file, we can’t start exporting it without breaking that merge:

// This merges with the global in lib.d.ts
interface String {
  reverse(): string;
}

// This is a reference to the value meaning of the same global in lib.d.ts
String.prototype.reverse = function (): string {
    return this.split("").reverse().join("");
}

Why don’t we want to export interface String when we move the prototype method definition here?

• Not because String.prototype... refers to a value while interface String refers to a type—this feels important, but they’re actually two different meanings of the same symbol!
• Not because String is a global type—if we had instead written interface Foo {} and moved the code type Bar = Foo, it would be true that Foo is a global type, but we make an assumption that most people want modules most of the time, and it’s probably a coincidence that they hadn’t made this file a module yet. In this case, we would actually start exporting interface Foo {}, converting it from a global type to an exported type. (Also, the same argument can be made for values, so being a type has nothing to do with it.)
• It’s because we can’t convert String from a global to an export by making modifications in this file alone—there are other definitions of String in other files, which increases our confidence that it’s actually intended to be a global.