refactor(ivy): introduce the 'core' package and split apart NgtscProgram (#34887)

Previously, NgtscProgram lived in the main @angular/compiler-cli package
alongside the legacy View Engine compiler. As a result, the main package
depended on all of the ngtsc internal packages, and a significant portion of
ngtsc logic lived in NgtscProgram.

This commit refactors NgtscProgram and moves the main logic of compilation
into a new 'core' package. The new package defines a new API which enables
implementers of TypeScript compilers (compilers built using the TS API) to
support Angular transpilation as well. It involves a new NgCompiler type
which takes a ts.Program and performs Angular analysis and transformations,
as well as an NgCompilerHost which wraps an input ts.CompilerHost and adds
any extra Angular files.

Together, these two classes are used to implement a new NgtscProgram which
adapts the legacy api.Program interface used by the View Engine compiler
onto operations on the new types. The new NgtscProgram implementation is
significantly smaller and easier to reason about.

The new NgCompilerHost replaces the previous GeneratedShimsHostWrapper which
lived in the 'shims' package.

A new 'resource' package is added to support the HostResourceLoader which
previously lived in the outer compiler package.

As a result of the refactoring, the dependencies of the outer
@angular/compiler-cli package on ngtsc internal packages are significantly
trimmed.

This refactoring was driven by the desire to build a plugin interface to the
compiler so that tsc_wrapped (another consumer of the TS compiler APIs) can
perform Angular transpilation on user request.

PR Close #34887

packages/compiler-cli/test/ngtsc/template_typecheck_spec.ts

@@ -1177,7 +1177,7 @@ export declare class AnimationEvent {
     it('should still type-check when fileToModuleName aliasing is enabled, but alias exports are not in the .d.ts file',
        () => {
          // The template type-checking file imports directives/pipes in order to type-check their
-         // usage. When `FileToModuleHost` aliasing is enabled, these imports would ordinarily use
+         // usage. When `UnifiedModulesHost` aliasing is enabled, these imports would ordinarily use
          // aliased values. However, such aliases are not guaranteed to exist in the .d.ts files,
          // and so feeding such imports back into TypeScript does not work.
          //