Adding a static factory for the TerminalLogger

[MichalPavlik]

Fixes #10998

Context

Although I created the SDK hotfix to always use the ConsoleLogger, we want to use TerminalLogger when it's possible.

Changes Made

Added a static factory that can return instance of Terminal or Console logger based on current environment. The usage of TerminalLogger in this scenario can be explicitly disabled by using of already existing env. variable or CLI argument --tl:[on|off].
This change also prevents emitting of progress indication when the verbosity is set to quiet.

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

src/MSBuild/TerminalLogger/TerminalLogger.cs:1089

• [nitpick] The variable name 'tlArg' is ambiguous. It should be renamed to 'terminalLoggerArgument' for better readability.

string tlArg = args?.FirstOrDefault(a => a.StartsWith("--tl:", StringComparison.InvariantCultureIgnoreCase)) ?? string.Empty;

src/MSBuild/TerminalLogger/TerminalLogger.cs:1087

• Ensure that the new behavior introduced by the 'CreateTerminalOrConsoleLogger' method is covered by tests.

public static ILogger CreateTerminalOrConsoleLogger(LoggerVerbosity verbosity, string[]? args)

[MichalPavlik]

@baronfel, I know you would like to have full support for CLI logger configuration, but it will require some refactoring as the code for argument parsing is mostly placed in XMake. I wanted to break up XMake years ago, but now we have a valid reason to refactor at least part of the huge file :) If you don't mind, I would create a separate issue for this work.

[baronfel]

LGTM, but should we use this factory in our own codebase to dogfood?

[baronfel]

@baronfel, I know you would like to have full support for CLI logger configuration, but it will require some refactoring as the code for argument parsing is mostly placed in XMake. I wanted to break up XMake years ago, but now we have a valid reason to refactor at least part of the huge file :) If you don't mind, I would create a separate issue for this work.

Yeah, that is quite a large unit of work - makes sense to carve it out.

[MichalPavlik]

LGTM, but should we use this factory in our own codebase to dogfood?

I wanted to do it from the beginning, but the entry point logic emits global messages when it detects that TL couldn't be used. The easiest solution is to make the list of deferred messages in XMake internal, but I don't like it from an engineering point of view (separation of concerns, class coupling, etc.).

I think we could move the factory to some already public type like ConsoleLogger, so the CLI doesn't have to use reflection. Then we could move the list of deferred messages from XMake to the Logger class and use it directly in the factory or, in a cleaner way, return some indication of why the TL cannot be used and let XMake create the messages. Let's sync offline.

Edit: I'm looking at XMake once again, and actually, there are multiple things that make dogfooding the factory... problematic :(