Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.62.0-dev
• OS Version: web

Steps to Reproduce:

1. Using the comments API from an extension, create a CommentThread with a Comment whose body is a plain string that incidentally contains Markdown syntax.
2. The comment is always rendered with body interpreted as Markdown, resulting in unexpected formatting.

This is relevant in situations where the comments fed into VS Code come from a code review system that either 1) does not support Markdown, meaning all comments are written under the assumption that they are rendered verbatim, or 2) gives the user a choice between writing plain-text comments or Markdown comments, meaning some comments are known to be written with the expectation to have Markdown formatting applied and some comments are known to be written with the expectation of being shown verbatim.

The "always-on" Markdown formatting is unexpected, because Comment.body is of type string | MarkdownString, which leads the user of the API to assume that plain strings will be rendered verbatim.

The current situation is cumbersome, because explicitly creating a MarkdownString from a plain string to trigger Markdown formatting is easy—just make a new object—while escaping all accidental Markdown syntax in a plain string known to not deliberately contain Markdown takes work and can be error-prone.

Expected behaviour:

The situation in 2) above means Markdown vs plain text treatment should not be a single switch on a given CommentController but should instead be configurable for each Comment. Since Comment.body already distinguishes string and MarkdownString on the type level, the more intuitive behaviour would be to require MarkdownString to trigger Markdown formatting—which is of course a breaking change for extensions relying on always-on Markdown at the moment.