Reimplement the panflute.stringify with native pandoc writer

[lwang2070]

Hi, I encountered some weird behaviours when using the battery function stringify. Similarly, someone else reported a bug with this function in #204.

After going through some documentation, I noticed that stringify basically creates its own implementation of a pandoc writer. It seems to me, however, that using pandoc to produce the corresponding raw text is a more reasonable choice, as is done in convert_text. Using the native implementation should result in both easier implementation and more robust behaviour.

Hope this could be considered!

Thanks Li

[sergiocorreia]

As far as I recall, there are two reasons for stringify:

1. It was part of the original pandocfilters implementation, so when I wrote panflute I kinda had to include it.
2. As you mentioned, convert_text calls Pandoc, but calling Pandoc is a quite expensive in terms of resources as it requires creating a new process altogether. It's not a problem if done once, but I've seen filters that call stringify multiple times (e.g. on every element of a given type) which would make it less practical.

Maybe an alternative would be to add an option to stringify, so you can do stringify(something, use_pandoc=True)? And of course, we could also try to improve on stringify, but that will never be as good as a native implementation and only works on relatively simple cases.

[sergiocorreia]

Closing as this might be less necessary now (stringify() is slightly improved and can be improved further). As an alternative we can always do convert_text, but as discussed it might be slow to call Pandoc multiple times from Python.