Chore: Add failing test case for indent of multiline fixes

[lydell]

If the replacement text of an autofix contains newlines, all lines but
the first in the replacement text will unexpectedly have 0 indentation
if a code block is indented. I guess not only the range of fixes but
also the text of fixes need to be adjusted.

If the code block is placed within a blockquote, a > character also
needs to be inserted.

This issue was found while investigating
lydell/eslint-plugin-simple-import-sort#22. That plugin fixes several lines
of imports in one go. This means that most of the imports will have too
little indentation after autofix if the code block is indented (such as
when placed in a list).

[lydell]

FYI: I don't intend to try to fix this issue at the moment. Just wanted to let you know about it.

[btmills]

Well this is fun. Thank you @lydell for creating the tests! I've started playing with a potential solution in my issue120 branch, and I've gotten the tests passing without breaking any other tests. What do you think? You're right that it needs to adjust the text of fixes, which it wasn't doing before. That branch inserts whatever leading text was found on the first line of the code block after each newline in a multi-line fix. I can't decide if that's so simple it can't possibly work, or simple enough that it just might do the trick.

[lydell]

Will it work with underindented code? This one is tricky because the first line has less indentation than the second. Does it matter?

   ```js
 console.log('Hello, world!')
  console.log("Hello, \
  world!")
     console.log('Hello, world!')
   ```

Here’s a similar case:

   ```js
  console.log('Hello, world!')
 console.log("Hello, \
 world!")
     console.log('Hello, world!')
   ```

This time the first line has more indenation. We must make sure that we don’t accidentally end up with more spaces in the JS string, altering its .length.

Here are two other test cases I’d like to see:

• CRLF tests.
• A code block inside a blockquote inside another blockquote.

[lydell]

Also, what does this while loop do?

    while (startOffset > 0 && text[startOffset - 1] !== "\n") {
        startOffset--;
    }

EDIT: Scratch that. You seem to have removed it in the PR anyway.

[btmills]

Take a look at #124. I added tests for underindenting and nested code blocks. The only caveat for underindenting is that it isn't preserved, though the fix is applied correctly. Example where the line was previously underindented by one level, and after the fix it matches the level of the fence. Extra indents are correctly preserved.

Good call on CRLF. I'm going to address that separately in #125 since it doesn't even require any indenting to fail. Pretty sure the cause is here:
https://github.com/eslint/eslint-plugin-markdown/blob/dc909618aa8f39e84279f5bdeb4a888d56d919b1/lib/processor.js#L180-L183

That line of code was a hack to get to the beginning of the line so I knew whether to add a blockquote character. Turns out I don't need to search backwards through the string; I can just do the math with the node's position, so it's gone in #124.