Respect node settings when rendering

[GuySartorelli]

As discussed in #9, various nodes have additional data explaining how they are intended to be rendered. For example, the fenced code node tells you its offset (indent), what delimiter character to use, and how many of that delimiter character should be used.

In some cases respecting this data will be useful only in that you're more likely to match the output to the given input - but in other cases ignoring that data can result in invalid (or at least incorrect) markdown. There's some examples of that in the above linked PR.

I've identified the following as not using the properties available when rendering nodes:

• StrongRenderer - ignores delimiter Update Strong and Emphasis Renderers to use settings available in AST Node #11
• EmphasisRenderer - ignores delimiter Update Strong and Emphasis Renderers to use settings available in AST Node #11
• HtmlBlockRenderer - ignores type
• IndentedCodeRenderer - doesn't actually render an indented code block - it's rendering a fenced code block - Fix rendering of indented code block #15
• ListBlockRenderer - ignores isTight; ignores delimiter, padding, bulletChar, markerOffset, start from ListData - Rework ListBlockRenderer and ListItemRenderer to respect node settings #12
• ListItemRenderer - ignores ListData (but maybe that's okay, since ListData is partially handled in ListBlockRenderer?) - Rework ListBlockRenderer and ListItemRenderer to respect node settings #12

[stefanzweifel]

This issue seems to be more complex than I thought. 😐

In #11 I've fixed StrongRenderer and EmphasisRenderer to use getOpeningDelimiter() and getClosingDelimiter().
(For v2 I will probably drop the use_asterisk and use_underscore config, if that's not something that's comming from commonmark itself; didn't check)

Ignoring type in HtmlBlockRenderer seems fine to me, as it doesn't seem it should make any impact, on how the node is rendered. (Feel free to drop any examples that teach me otherwise)

IndentedCodeRenderer needs redoing. Looking at the code, I now remember that I really struggled to find exact examples of what each renderer should look like, when I developed this package.

ListBlockRenderer and ListItemRenderer: These definitely need an overhaul. In #7 I've fixed an issue with multi-line list items, with a solution that always felt like a cheap fix.

I need some more head-space to tackle this. And the package definitely needs a better test-suite. The current tests have all been inspired by the league/commonmark suite, but it always felt a bit too unit-testy for me.
Will update the kitchen-sink.md with a bit more examples to make testing a bit more straight forward.

[GuySartorelli]

Regarding the HTML block, here's the commonmark spec: https://spec.commonmark.org/0.30/#html-blocks
It lists 7 different ways a HMTL Block can be declared.

I haven't tested to see if, for example, <![CDATA[ is included in the value you get from $node->getLiteral(). If it is, then it probably wouldn't hurt to add a quick comment that says something like "We can ignore the type because it's included in the literal for this node type". If not some new test cases to validate that doesn't change.

[GuySartorelli]

Closing since all of the identified items have been resolved - outstanding issues such as nested lists already have GitHub issues to track.