Remove internal uses of "namespace barrel" modules, untangle repo

[jakebailey]

In #51387, I introduced the concept of the "namespace barrel" modules, located at **/_namespaces/*.ts.

While this does help us transition to modules, internally, this is a gross hack and makes it hard for us to start splitting the codebase up, export just the parser, etc.

We should be trying to remove internal uses of these files and use direct imports, leaving these files for our public API surface only.

[jakebailey]

Low hanging fruit for untangling: typeHasCallOrConstructSignatures is defined as a helper, but is then used by the checker. This should be flipped and that's one cycle down.

[a-tarasyuk]

While this does help us transition to modules, internally, this is a gross hack and makes it hard for us to start splitting the codebase up

@jakebailey Do you mean it's better to use

// @filename: core.ts
import { Debug } from "./debug";
import { __String, CharacterCodes, Queue, TextSpan, UnderscoreEscapedMap } from "./types";
import { Comparer, Comparison, EqualityComparer, MapLike, Push, SortedArray, SortedReadonlyArray } from "./corePublic";
import { isWhiteSpaceLike } from "./scanner";
....

instead of

// @filename: core.ts
import {
    __String, CharacterCodes, Comparer, Comparison, Debug, EqualityComparer, isWhiteSpaceLike,
    MapLike, Push, Queue, SortedArray, SortedReadonlyArray, TextSpan,
    UnderscoreEscapedMap,
} from "./_namespaces/ts";
...

?

Or do you mean that we need to avoid import * as ts from "./_namespaces/ts";?

[jakebailey]

Yes, the first one, not the last two. Reasons being:

1. This is how we would have written things if we had been modules from the start.
2. By going through the barrels, we make cycles harder to resolve. For example, core.ts should not be depending on scanner.ts. That code should be moved.