Expose stable machine-readable Angular build diagnostics

### Which @angular/* package(s) are relevant/related to the feature request?

compiler-cli

### Description

Large Angular codebases often want to enable stricter compiler checks, especially `strictTemplates` and extended diagnostics, but cannot fix all existing diagnostics in one migration.

Angular already supports category-based strictness ratcheting through template type-checking flags. That helps when a whole category of checks is too noisy.

It does not solve the case where a team wants a check enabled, but wants to treat existing diagnostics as migration debt while preventing new diagnostics from being introduced.

Teams can build this externally by parsing `ng build` output, but text output is not a stable API. Angular diagnostics can include template source spans and compiler-specific formatting, which makes external parsing fragile.

This is not a request for `strictTemplates` warning mode. A previous discussion in [https://github.com/angular/angular/issues/55868](https://github.com/angular/angular/issues/55868) explained why warning mode is not a good fit for `strictTemplates`, especially because template type-checking often produces TypeScript diagnostics from generated template-checking code.

This request is only about exposing stable diagnostic output so external tooling can implement baseline/ratchet workflows reliably.

### Proposed solution

Expose stable machine-readable diagnostics from Angular CLI builds.

For example:

```bash
ng build my-app --configuration strict-check --diagnostics-format json
```

or:

```bash
ng build my-app --configuration strict-check --diagnostics-output angular-diagnostics.json
```

The exact CLI/API shape is not important. The important part is that `ng build` can emit stable, machine-readable diagnostics.

Example shape:

```jsonc
{
"diagnostics": [
{
"code": "NG8002",
"category": "error",
"source": "angular-template",
"message": "Can't bind to ...",
"file": "libs/example/src/example.component.html",
"startLine": 12,
"startColumn": 7,
"endLine": 12,
"endColumn": 28,
"relatedInformation": []
}
]
}
```

The schema should include enough stable information for tools to compare diagnostics across runs, such as diagnostic code, category/severity, source, file, source span, message, and related information when available.

This would enable external workflows like:

```bash
ng build my-app --configuration strict-check --diagnostics-output angular-diagnostics.json
angular-baseline check angular-diagnostics.json
```

That allows teams to create a migration ratchet:

* Existing diagnostics are treated as migration debt.
* New diagnostics fail CI.
* Fixed diagnostics can be removed from the baseline.
* The codebase becomes stricter over time.

This is similar in spirit to `tsc-baseline` or ESLint bulk suppressions, but for Angular compiler and template diagnostics.

### Alternatives considered

## Use existing template strictness flags

Angular's existing strictness flags are useful for category-based rollout.

However, disabling a category allows both existing and new violations in that category.

A diagnostic baseline lets a team keep the check enabled while allowing only known existing diagnostics.

## Parse `ng build` text output

Teams can parse `ng build` output today, but this is fragile because CLI text output is optimized for humans, not long-term machine consumption.

## Add first-class Angular diagnostic baselines

Angular could provide a full diagnostic baseline feature directly, for example:

```bash
ng build my-app --configuration strict-check --update-diagnostic-baseline
ng build my-app --configuration strict-check --diagnostic-baseline angular-diagnostics.baseline.json
```

That would be useful, but stable machine-readable diagnostics would already allow the ecosystem to build this externally.

Bắt đầu với package compiler-cli và entry point ng build, sau đó lần theo để xác định nơi các diagnostic của Angular compiler và template được tạo và định dạng. Xác định và ghi lại một đầu ra ổn định, có thể đọc bằng máy, chứa các trường diagnostic được yêu cầu, đồng thời xác minh rằng một strict-check build có thể xuất đầu ra đó cho các công cụ baseline bên ngoài.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.