Add context menu to disable rule for line or file scope

[nschonni]

Like what https://github.com/microsoft/vscode-eslint does in that it allows for disabling through the inline comments at either the file or line scope, when you don't want to globally disable a rule (like asked in https://github.com/DavidAnson/vscode-markdownlint/issues/210)

[DavidAnson]

I like what you propose better, actually, and added your suggestions into that issue for tracking. I never felt like I had a good plan for how/where to enable globally, so using an approach like yours or using local file overrides seems pretty appealing right now.

Actually, I guess I will leave the two issues separate for now, but what I'm guessing will happen is that I implement this one and decline that one.

[nschonni]

I didn't dig through the other repo very far, but I figure there might be some code to get inspiration from

[DavidAnson]

I'll look at their documentation for how they've approached this, but I don't look at code for other projects to avoid the risk of licensing, etc. issues.

[DavidAnson]

I've thought about how to do this for line scope and the challenge is that problems quickly arise with how/where to add the suppression comment:

Adding markdownlint-disable-line to the end of the line can break scenarios like:

`Code with space ` and hard break  <!-- markdownlint-disable-line no-space-in-code -->
Text text text

Using markdownlint-disable-next-line instead can break for scenarios like:

```code
<!-- markdownlint-disable-next-line blanks-around-fences -->
```
Text text text

Using markdownlint-disable paired with markdownlint-restore may need the two comments to be pretty far apart to avoid problems like the examples above - and that risks suppressing more than just the intended warning.

Using markdownlint-disable at the top of the file or markdownlint-disable-file at the bottom of the file could both work, but suppress many, many warnings - and at that point you should probably change the linting configuration instead.

markdownlint-disable-file is my current best idea, but I don't like it much for line scope. For file scope, I think it can work, but I worry about encouraging the wrong behavior: "Ugh, it's such a pain to open every file and disable the rules I don't like".

[nschonni]

Personally, I'd probably use the next-line more often, and I'd probably be OK if the inserts were not really that context aware. I think if the disable comment is added but doesn't work, its not the end of the world. You'd probably start to get a few edge case reported at the beginning