Expose method(s) to send message/warning/error

[Evangelink]

Summary

Expose method(s) to send message/warning/error.

Background and Motivation

VSTest and the new platform offer capabilities to send messages to a client (e.g. Test Explorer) with Info/Warning/Error "levels". As part of the fixture methods when some processing is taking a long time, it would be nice to emit messages.

For examples, in Playwright, they are doing many "slow" downloads and install during [AssemblyInitialize] and having a basic level of progress report would be appreciated by users.

Proposed Feature

Add either one method with an enum for "level" or multiple methods to send these messages. Given we are using VSTest bridge we can send them all with IMessageLogger.

I am not sure what's the best naming to use so that's clear for users what's the difference between TestContext.WriteXXX methods and these new APIs.

[Evangelink]

Here are some naming suggestions:

1. OutputMessage
   Pros: Explicitly conveys the idea of generating output.
   Cons: The term "Output" might feel generic and lacks an active or intentional tone, which might make it seem less focused on communication or logging.

2. SendMessage
   Pros: Feels active and intentional, suggesting a directed action (sending the message).
   Cons: "Send" might imply networking or inter-process communication, which isn't the intended use here.

3. ReportMessage
   Pros: Conveys the intent to report something, aligning well with diagnostics or logging.
   Cons: Might be slightly misleading, as "Report" can imply more structured reporting (e.g., generating a report) rather than a simple log or output.

4. LogMessage
   Pros: Common in diagnostic or testing contexts. Directly implies logging a message for output or diagnostic purposes.
   Cons: Might overlap conceptually with a separate "logging" system if MSTest supports logging libraries.

5. WriteMessage
   Pros: Simple and clear. "Write" aligns naturally with the act of writing to an output medium.
   Cons: Could be confused with low-level writing (e.g., file I/O).

6. PrintMessage
   Pros: Intuitive for console or terminal scenarios.
   Cons: Less fitting for abstract output systems like IDEs, as "print" might evoke physical printing or console use.

7. DisplayMessage
   Pros: Immediately conveys that the message is meant to be shown to the user, regardless of the medium (console, terminal, IDE, etc.).
   Cons: In the context of test frameworks or diagnostics, "Display" isn't as standard as terms like "Log" or "Output."

I would personally vote for DisplayMessage as:

• it betters align with MTP API
• it provides a clear user-facing intent
• it feels more abstract than terms like Print or Write
• it avoids associations with specific mechanisms like logging, file I/O, or inter-process communication.