New rule: Prevent lazy continuation lines

[skwde]

This is somewhat related to MD032 and emerged from #972

Lazy line conditions make the markdown file less readable. That is because

1. abc
2. def
ghi

behave the same like standard lists

1. abc
2. def
   ghi

Even more confusing/weird is the behavior when using multiple levels like

- abc
  + def
ghi

where ghi goes to the 2nd indent level.

In addition, as mentioned in https://github.com/DavidAnson/markdownlint/blob/main/doc/md032.md some parsers do not parse lists if they are not surrounded by blank lines. MD032 is however only concerned with the starting line because it cannot know when it should be a lazy line continuation or when the list is done.

[BlaineEXE]

Ditto. This would be a great add :)

[amyq]

Chiming in here. My coworker Marcel (@Ravlen) and I have been talking about this problem over in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/155088 for the GitLab docs. He's trying to construct a rule in Vale to error out on (what I now know are) lazy continuation lines.

While lazy continuation lines are valid CommonMark, I agree with Marcel - when managing Markdown-formatted docs at scale, our technical writing team would find it helpful to prevent them from creeping into our docs. It feels like a good rule to leave off by default, but make available to users who need every scrap of scannability improvements they can get.

[Ravlen]

Yeah, 👍 from me, though I think this is a repeat of the request in #344, where I've got a non-breaking change suggestion that could work in #344 (comment)