Add user setting to enable/disable Markdown editor "intelligence" / RTE behavior

Proposal

As a user who understands Markdown, I want to type Markdown into textboxes without modification so that I am not fighting against the editor.

I propose that users should be able to opt out of "intelligent" or "RTE-like" behaviors via user settings.

The Markdown editor for issue descriptions/comments, MR descriptions, etc. currently attempts to insert text automatically in some situations. Automatic text insertion is presumably aimed at users who are accustomed to rich text editors (RTEs); it is a common benefit of writing in an RTE that formatting elements may be automatically inserted as continuations of the current formatting "context".

For users that are fluent in Markdown, though, auto-inserted text can be detrimental to the act of writing. Due to the textbox-like nature of GitLab's Markdown editor, certain behaviors that have been replicated from RTEs are in some cases less fluent. As a result, a user may find themselves less effective at writing Markdown, and the editor's attempts at helpfulness end up being an impediment.

A specific example: lists.

In an RTE,

pressing Enter at the end of a list item automatically inserts the next bullet point or ordered label to continue the list
when a new ordered label is inserted into the middle of the list after pressing Enter, subsequent ordered labels are updated simultaneously so that all ordered labels form a continuous sequence
when the cursor is at the start of a list item, a writer can use Tab/Shift+Tab to change indentation level

In GitLab's Markdown editor,

pressing Enter at the end of a list item has the same behavior, but
- ordered alphabetical labels are not supported, and
- ordered numeric labels automatically increment, despite this not being necessary for valid Markdown — indeed, the rendered Markdown ignores the literal numeric label
when a new ordered label is inserted into the middle of the list after pressing Enter, subsequent ordered labels are not updated simultaneously, leading to inconsistent enumeration
a writer cannot use Tab/Shift+Tab to change indentation level, and
- after pressing Enter at the end of an ordered list item, the cursor is placed after the numeric label, often necessitating the removal of auto-inserted text before adding the desired indentation

Given this valid target Markdown:

1. First item
1. Second item
    1. Second item, first sub-item
    1. Second item, second sub-item
1. Third item
1. Fourth item

The following sequence of events could occur in the RTE-like editor:

Input	Rendered	Comments
		Correct render, but must backspace to achieve target
		Inserted label increments despite indication that normal Markdown with repeating `1.` is desired; further edits required to indent
		Naively inserting spaces before auto-inserted `2.` to create indent results in undesirable render; writer must undo auto-inserted text in order to fix
		For outdent, writer must delete auto-inserted text and spaces (not a major task)
		Auto-inserted text `2.` does not correspond to render, so why bother?

The behavior of the GitLab Markdown editor even seems to contravene GitLab's own documentation on Markdown lists (emphasis mine):

For an ordered list, add the number you want the list to start with, like 1., followed by a space, at the start of each line for ordered lists. After the first number, it does not matter what number you use. Ordered lists are numbered automatically by vertical order, so repeating 1. for all items in the same list is common. If you start with a number other than 1., it uses that as the first number, and counts up from there.

It may be the case that users who favor an RTE experience prefer the current behavior and future direction of the RTE-like GitHub Markdown editor. Nonetheless, I would wager that a significant portion of GitLab users write code, and unhelpful text insertion is a natural point of frustration for that type of user. Instead of subtracting from an experience that may be of benefit to others, I only ask that there should be an escape valve for those who are — in the context of Markdown — power users.