Markdown docs refactor: Put examples in block quotes

What does this MR do?

This page has a lot of edge cases for how we handle markdown formatting. Sometimes we use unicode to get around linting rules, or other formatting tweaks. This can cause trouble with localization as it struggles to handle our little tricks.

On top of this, while working on this page, I realized that the page is hard to parse quickly when examples are not clearly differentiated from the rest of the text (essentially, in "plain text").

But if we put "rendered" examples in block quotes, it actually solves a lot of problems at once. It means we can drop a lot of our exceptions (which do not expect > at the start of lines), while at the same time making the page much easier to parse.

Review app: https://docs.gitlab.com/upstream-review-mr-ee-189873/user/markdown/

Improvements:

1. Put the majority of examples in block quotes. This makes it much easier to see what is a rendered example, and what is introductory/explanatory text. See screenshots below.
   It also has a side benefit of allowing us to skip some of our little exceptions/hacks.

2. Removes all the View this topic rendered in GitLab links. These are problematic for a variety of reasons. For example, with the math section: https://docs.gitlab.com/user/markdown/#math-equations

   • Links get stale as they are not internal/relative links and are not checked with lychee. For example, the link in the Math section is invalid: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/user/markdown.md#math (the anchor should be `#math-equasions).
   • The content we're linking to in this section is no different than the docs site, as it's just a screenshot.
   • If the users look at the raw markdown, they only see the screenshot markdown link.

   For another example, sending people to the raw Markdown also shows the hacks and tricks we've done, which we shouldn't be pointing people to:

   • https://gitlab.com/gitlab-org/gitlab/-/blob/3e4d60a36047d0b339034ed3f0941f39834d8310/doc/user/markdown.md?page=2#L1205
   • https://gitlab.com/gitlab-org/gitlab/-/blob/3e4d60a36047d0b339034ed3f0941f39834d8310/doc/user/markdown.md#L649

3. Near the top of the page, tells people to copy the raw markdown examples into GitLab themselves when they want to see how it renders in GitLab. This is what I always do, I never check this file if I want to see how it renders for real.

Related issues

• Related to Feedback on Japanese translations rendering fro... (gitlab-com/localization/docs-site-localization#179)
• Related to Improve GitLab flavored Markdown, AsciiDoc, and... (#516860 - closed)
• Closes Improve the "View this topic in GitLab" note in... (#373018 - closed)

Screenshots

Before	After

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.