Add possibility to format the changelog in slack-specific markdown

[AlexPl292]

In IdeaVim project we use this plugin (and used to use hand-hacked script before this plugin was created) to send the changelog to the slack. Unfortunately, Slack uses some sort of fancy markdown, so the normal markdown doesn't render properly.
I've created a small lib that converts GitHub markdown into the Slack-specific markdown and I think it would be convenient to include it to this project.
There is also an option to create a separate gradle plugin (or anything else) that converts GH markdown to slack markdown and use it separately from this plugin, but I think that this would be more convenient to have everything in one place.

[hsz]

I'm happy to hear that it's useful for your project!
I think that support for the Slack Markdown will be beneficial.
But since the Changelog plugin is also using the org.intellij.markdown parser, wouldn't it be more reasonable to extend it with another GFMFlavourDescriptor?

[AlexPl292]

Thank you for the response. I haven't worked with markdown plugin before, so I'll check how GFMFlavourDescriptor works and how can I use it if you think it would be more reasonable.

[AlexPl292]

Hey, I've checked MarkdownFlavourDescriptor and GeneratingProviders and I have some doubts about using them in this library. It looks like they are built in order to build an HTML file and the slack-md isn't HTML. So I'll need to use some methods like consumeHtml or consumeTagOpen what would look incorrect even I'll get the correct result.

Another thing that bothers me more is that element types without GeneratingProvider are defaulted to empty text. That means that I would have to define providers for all element types in order not to lose some data. And I was actually thinking about rendering unknown element types "as it is" and define only necessary renderers.

Both things I've described above are about the internal implementation of the library. Taking this particular plugin I can't say that I see a benefit from using a MarkdownFlavourDescriptor instead of DownParser(input).toSlack() because it's still String to String conversion. I mean, for example, if the gradle-changelog had parsed the markdown text for internal use and my library was parsed this again, that would make sense to add the possibility to reuse the constructed AST, but if I don't miss anything, I don't do any additional job at the moment because the text isn't processed yet. Also, MarkdownFlavourDescriptor doesn't have any special optimizations except for using StringBuilder instead of String concatenation, what I'm going to fix soon (again, if I don't miss anything).