perf(compiler-cli): perform template type-checking incrementally (#36211)

This optimization builds on a lot of prior work to finally make type-
checking of templates incremental.

Incrementality requires two main components:
- the ability to reuse work from a prior compilation.
- the ability to know when changes in the current program invalidate that
  prior work.

Prior to this commit, on every type-checking pass the compiler would
generate new .ngtypecheck files for each original input file in the program.

1. (Build #1 main program): empty .ngtypecheck files generated for each
   original input file.

2. (Build #1 type-check program): .ngtypecheck contents overridden for those
   which have corresponding components that need type-checked.

3. (Build #2 main program): throw away old .ngtypecheck files and generate
   new empty ones.

4. (Build #2 type-check program): same as step 2.

With this commit, the `IncrementalDriver` now tracks template type-checking
_metadata_ for each input file. The metadata contains information about
source mappings for generated type-checking code, as well as some
diagnostics which were discovered at type-check analysis time. The actual
type-checking code is stored in the TypeScript AST for type-checking files,
which is now re-used between programs as follows:

1. (Build #1 main program): empty .ngtypecheck files generated for each
   original input file.

2. (Build #1 type-check program): .ngtypecheck contents overridden for those
   which have corresponding components that need type-checked, and the
   metadata registered in the `IncrementalDriver`.

3. (Build #2 main program): The `TypeCheckShimGenerator` now reuses _all_
   .ngtypecheck `ts.SourceFile` shims from build #1's type-check program in
   the construction of build #2's main program. Some of the contents of
   these files might be stale (if a component's template changed, for
   example), but wholesale reuse here prevents unnecessary changes in the
   contents of the program at this point and makes TypeScript's job a lot
   easier.

4. (Build #2 type-check program): For those input files which have not
   "logically changed" (meaning components within are semantically the same
   as they were before), the compiler will re-use the type-check file
   metadata from build #1, and _not_ generate a new .ngtypecheck shim.
   For components which have logically changed or where the previous
   .ngtypecheck contents cannot otherwise be reused, code generation happens
   as before.

PR Close #36211

packages/compiler-cli/src/ngtsc/incremental/api.ts

@@ -14,12 +14,19 @@ import {AbsoluteFsPath} from '../file_system';
  *
  * `W` is a generic type representing a unit of work. This is generic to avoid a cyclic dependency
  * between the incremental engine API definition and its consumer(s).
+ * `T` is a generic type representing template type-checking data for a particular file, which is
+ * generic for the same reason.
  */
-export interface IncrementalBuild<W> {
+export interface IncrementalBuild<W, T> {
   /**
    * Retrieve the prior analysis work, if any, done for the given source file.
    */
   priorWorkFor(sf: ts.SourceFile): W[]|null;
+
+  /**
+   * Retrieve the prior type-checking work, if any, that's been done for the given source file.
+   */
+  priorTypeCheckingResultsFor(sf: ts.SourceFile): T|null;
 }
 
 /**