Assess / Increase test coverage of Markdown/KDoc parsing and analysis

[IgnatBeresnev]

Context

At this moment, there are some tests that check Markdown parsing and analysis, but it's not very clear which cases are covered and how much we can trust them, because everything is in one huge file with little to no documentation.

Task

We should assess the state of existing tests, see what they check and try to break them down into multiple blocks (test classes / suites). Once that's done, we should be able to see which areas and cases are not covered.

The big chunks (suites) could be the following:

1. Basic and trivial cases, like headers, code blocks, lists, quotes and so on - all should be covered and work as expected.
2. Cover cases specific to the specification of Markdown that KDoc chooses (see the note below). markdown parser tests #2029 adds some tests for the commonmark spec, the PR should be salvageable.
3. KDoc-specific constructs, like links to declarations, like this text links to [a function][functionName]. Some details can be found here.
4. Other non-trivial corner cases, especially on the intersection of everything described above.

Each one could be broken down even further. For instance, to make sure that KDoc links work as expected, it will likely require a dozen tests that cover different cases, so it makes sense to extract it into a separate class which will be invoked as part of the parent KDoc suite. Same goes, for example, for markdown lists, which have multiple variations and corner cases.

Note on the spec

At the moment, it's unclear which specification or flavour KDocs should adhere to, in the documentation it's stated just as "Markdown".

Dokka itself uses GFM flavoured Markdown for analysis, and adds special handling of GFM-specific formatting like strikethrough.

Whether the current approach is correct is to be discussed, but it likely is, we just need to make it a formal decision and reflect it somewhere in documentation.

Technical details

The tests should check specifically that both KDocs and module/package documentation are parsed correctly and into the expected DocTags.