feat(ivy): enable re-export of the compilation scope of NgModules privately (#33177)

This commit refactors the aliasing system to support multiple different
AliasingHost implementations, which control specific aliasing behavior
in ngtsc (see the README.md).

A new host is introduced, the `PrivateExportAliasingHost`. This solves a
longstanding problem in ngtsc regarding support for "monorepo" style private
libraries. These are libraries which are compiled separately from the main
application, and depended upon through TypeScript path mappings. Such
libraries are frequently not in the Angular Package Format and do not have
entrypoints, but rather make use of deep import style module specifiers.
This can cause issues with ngtsc's ability to import a directive given the
module specifier of its NgModule.

For example, if the application uses a directive `Foo` from such a library
`foo`, the user might write:

```typescript
import {FooModule} from 'foo/module';
```

In this case, foo/module.d.ts is path-mapped into the program. Ordinarily
the compiler would see this as an absolute module specifier, and assume that
the `Foo` directive can be imported from the same specifier. For such non-
APF libraries, this assumption fails. Really `Foo` should be imported from
the file which declares it, but there are two problems with this:

1. The compiler would have to reverse the path mapping in order to determine
   a path-mapped path to the file (maybe foo/dir.d.ts).
2. There is no guarantee that the file containing the directive is path-
   mapped in the program at all.

The compiler would effectively have to "guess" 'foo/dir' as a module
specifier, which may or may not be accurate depending on how the library and
path mapping are set up.

It's strongly desirable that the compiler not break its current invariant
that the module specifier given by the user for the NgModule is always the
module specifier from which directives/pipes are imported. Thus, for any
given NgModule from a particular module specifier, it must always be
possible to import any directives/pipes from the same specifier, no matter
how it's packaged.

To make this possible, when compiling a file containing an NgModule, ngtsc
will automatically add re-exports for any directives/pipes not yet exported
by the user, with a name of the form: ɵngExportɵModuleNameɵDirectiveName

This has several effects:

1. It guarantees anyone depending on the NgModule will be able to import its
   directives/pipes from the same specifier.
2. It maintains a stable name for the exported symbol that is safe to depend
   on from code on NPM. Effectively, this private exported name will be a
   part of the package's .d.ts API, and cannot be changed in a non-breaking
   fashion.

Fixes #29361
FW-1610 #resolve

PR Close #33177

packages/compiler-cli/src/transformers/api.ts

@@ -260,6 +260,37 @@ export interface CompilerOptions extends ts.CompilerOptions {
    * @internal
    */
   ivyTemplateTypeCheck?: boolean;
+
+  /**
+   * Enables the generation of alias re-exports of directives/pipes that are visible from an
+   * NgModule from that NgModule's file.
+   *
+   * This option should be disabled for application builds or for Angular Package Format libraries
+   * (where NgModules along with their directives/pipes are exported via a single entrypoint).
+   *
+   * For other library compilations which are intended to be path-mapped into an application build
+   * (or another library), enabling this option enables the resulting deep imports to work
+   * correctly.
+   *
+   * A consumer of such a path-mapped library will write an import like:
+   *
+   * ```typescript
+   * import {LibModule} from 'lib/deep/path/to/module';
+   * ```
+   *
+   * The compiler will attempt to generate imports of directives/pipes from that same module
+   * specifier (the compiler does not rewrite the user's given import path, unlike View Engine).
+   *
+   * ```typescript
+   * import {LibDir, LibCmp, LibPipe} from 'lib/deep/path/to/module';
+   * ```
+   *
+   * It would be burdensome for users to have to re-export all directives/pipes alongside each
+   * NgModule to support this import model. Enabling this option tells the compiler to generate
+   * private re-exports alongside the NgModule of all the directives/pipes it makes available, to
+   * support these future imports.
+   */
+  generateDeepReexports?: boolean;
 }
 
 export interface CompilerHost extends ts.CompilerHost {