Support language-specific codefence renderers

[tt]

I was looking for a way to render Pikchr diagrams. I'm porting some code from Go where I used goldmark and the goldmark-pikchr extension which support this through fenced code blocks.

I thought of different ways to support this:

1. Pikchr could be officially supported either generally or through a named feature. This would solve my particular need but isn't particularly extensible.

2. Implement SyntaxHighlighterAdapter and short-circuit the rendering of a particular language. The problem with this is that you can't opt out of the closing </code> and </pre> tags:
   

   comrak/src/html.rs

   Line 644 in 8d30848

   self.output.write_all(b"</code></pre>\n")?

3. Pre-render certain CodeBlock nodes to HtmlBlock. My one problem with this approach is that it ended up being more code than ideal and it didn't feel right.

4. Allow a way to register language-specific renderers. I liked this the best and there's even some prior art in Add math support #366:
   

   comrak/src/html.rs

   Lines 575 to 576 in 8d30848

   	if ncb.info.eq("math") {
   	self.render_math_code_block(node, &ncb.literal)?;

I would not be opposed to contributing Pikchr as a gated feature if it would be useful to others but I like adding the general capability to allow experimenting with it and other language-specific renderers.

Anyway, I opened this draft pull request so there's something concrete to discuss. If we agree that this is the preferred approach, I'll add tests, improve the documentation and address eventual feedback.

[tt]

Arguably, this could be converted to a language-specific renderer that's registered by default.

[digitalmoksha]

Hmm, interesting. The way I've done it is process the HTML using Nokogiri, and then process any code blocks that have the graph languages I support, such as mermaid, plantuml, kroki.io (which also supports pikchr), etc.

But I can see the utility of being able to have a plugin that handles registered language extensions.

[kivikakk]

I'm quite a fan of this approach, and would be happy to merge it. (Likewise, refactoring the math codeblock support to use it!)