Enhance the MSBuild output experience for CI/CD providers

[baronfel]

Summary

MSBuild today doesn't nicely integrate into CI/CD providers, so diagnostics from the build are not reported in a way that providers can easily integrate into their summaries/displays. We should create provider-specific loggers and detections that auto-enable those providers in lieu of any explicit ConsoleLogger or TerminalLogger specification by the user.

Background and Motivation

This is a relatively simple way to enhance the user experience of MSBuild that is straightforward to accomplish.

Proposed Feature

We should create new loggers for

• GitHub Actions
• Azure DevOps
• GitLab
• Other user-suggested providers

To reduce the duplication of those loggers, we should build these as different 'formatters' on top of the better logical model that #12587 introduces.

Each of these loggers should

• expose a detection criteria for if that logger should be used that's based on the environment variables described by that CI/CD provider in their documentation
• use the provider-specific mechanisms for communicating diagnostics, source files and locations, and additional data as described by the CI/CD provider in their documentation
• be a 'distributed logger' in MSBuild parlance so that we can filter events from worker nodes that are sent to the central node
• if the CI/CD provider supports reporting 'progress' then the per-node information exposed by separate the tracking parts of TL into a reusable base, so that TL becomes a 'renderer' #12587 can be used to drive that experience

When MSBuild's command line is processing the Logger configuration to use, if neither console logger nor terminal logger have been explicitly specified then the available CI/CD provider-specific loggers are checked to see if any are applicable to the current execution environment. If there is one and only one match, that logger should be used instead of the console or terminal logger.

Alternative Designs

No response