MD046 assumes block indents are bad if they are a part of lists.

Description

MD046 incorectly flags all fenced code blocks as violations even if they are a part of lists.

Motivating example:

1. Here is my list item

    ```bash
    # example code
    ```
2. Here is my next list item.

which I expect to render as follows:

---

1. Here is my list item

   # example code
   

2. Here is my next list item.

---

The vscode markdownlint extension flags this as a violation of MD046 but if I follow the advice on the MD046 wiki page then I get the following rendering:

Example following MD046 advice:

1. Here is my list item

```bash
# example code
``` <!-- space added here to prevent rendering errors in comment-->

2. Here is my next list item.

Rendered result:

---

1. Here is my list item

# example code

1. Here is my next list item.

---

which is not how I want the list to appear in its rendered form.

Possible Resolutions:

It seems like there are two approaches that could be used to fix this issue:

1. broaden MD046 to allow for these cases when in lists. (both formations are valid so it probably just needs to be disabled when immediately following list items (ordered or unordered)
2. Allow the visual studio code extension to ignore specific violations.

[DavidAnson]

@MichaIng Your failing test run reports an issue with docs/dietpi_tools.md, but your example and link are for a different file.

Looking at the reported file, we see code fences on lines 7 and 17, so the report of an indented code block on line 27 being inconsistent is correct.

https://github.com/MichaIng/DietPi-Docs/blame/b9ac99eab398f0b850eac7460ea8267f06bf0c4e/docs/dietpi_tools.md

[MichaIng]

Many thanks for mentioning CommonMark, good to know there is such a specification, only sad that Python-Markdown core + standard library extensions do not fulfil it completely (e.g. fenced code in list items is not possible) so that pymdownx needs to be used for that, while other extensions of pymdownx are not part of CommonMark. Not a real issue but that makes it difficult for newcomers to differentiate between common/specified syntax that is usually interpreted correctly and uncommon syntax where one has to expect failures of code quality/syntax tests 😅.

But all fine, I see that these content tabs a very uncommon and conflict with some header and thematic break syntax. So the effort to implement support is likely too large effort to be reasonable.