[MVP] Add native CI logging for GitHub Actions

### Summary

Create the first minimum viable CI logging experience described by #12737, scoped to GitHub Actions.

The MVP will convert existing MSBuild errors and warnings into native GitHub Actions annotations with source paths and locations while preserving existing console and binary logging behavior. Implementation will proceed incrementally with GitHub Copilot and be tracked through sub-issues.

### Background and Motivation

MSBuild currently writes diagnostics as console text. In GitHub Actions, users must inspect the build log to locate failures, and diagnostics are not consistently surfaced as native, clickable annotations.

GitHub Actions workflow commands can report errors and warnings with source locations. An MSBuild logger can use this protocol to make build problems easier to find and navigate to.

The implementation belongs in MSBuild because MSBuild owns build events, logger registration, distributed event forwarding, warning promotion, and interaction with console and binary loggers. The .NET SDK may later enable the logger by default for `dotnet` commands, but it should not own the implementation.

### Proposed Feature

#### Goal

Improve the MSBuild experience in GitHub Actions by converting existing errors and warnings into native, clickable annotations. Establish reusable infrastructure for future CI/CD providers.

#### MVP scope

Included:

- explicit opt-in, with an `auto` mode that detects GitHub Actions;
- error and warning annotations with diagnostic code, message, file, line, and column when available;
- paths relative to `GITHUB_WORKSPACE`;
- multiprocess build support;
- unchanged Console Logger and Binary Logger behavior;
- validation on GitHub-hosted Windows and Linux runners;
- graceful failure of supplemental CI output.

Out of scope:

- automatic default activation;
- providers other than GitHub Actions;
- summaries, grouping, and provider-limit policies;
- individual failed-test annotations;
- separate package or setup-action distribution.

#### Proposed architecture

MSBuild will provide a provider-independent CI logger and provider-specific output writers. Detailed designs are tracked in the relevant sub-issues.

#### Implementation tracking

Implementation work is tracked as sub-issues and should proceed in this order:

1. [#14651 — Introduce `BuildEventTracker` and migrate `TerminalLogger`](https://github.com/dotnet/msbuild/issues/14651)
2. [#14650 — Implement provider-independent `CiLogger`](https://github.com/dotnet/msbuild/issues/14650)
3. [#14654 — Implement GitHub Actions CI writer](https://github.com/dotnet/msbuild/issues/14654)
4. [#14652 — Add activation and distributed logging](https://github.com/dotnet/msbuild/issues/14652)
5. [#14653 — Add fixtures and GitHub Actions dogfood workflow](https://github.com/dotnet/msbuild/issues/14653)

The first four steps are sequential. Fixture preparation may begin earlier, but final dogfood validation depends on the preceding implementation work.

#### Validation

Use focused unit and integration tests plus a GitHub Actions dogfood workflow that builds MSBuild and exercises deterministic diagnostic fixtures with bootstrap MSBuild.

### Alternative Designs

Implementing the logger in the .NET SDK or distributing it separately would complicate ownership and acquisition. The SDK should control possible future default activation, while MSBuild owns the logger implementation.