Remove obsolete/experimental pandoc package

[Omikhleia]

This PR is another clean-up proposal, but I kept its separate from #1610 because the things at stakes are a bit different and I want to take the time properly advocating and discussing.

Rationale for removal

• It's undocumented in the SILE manual
• It's not covered by any test
• It has no use unless one builds a special version/branch of Pandoc without it coming upstream in any visible/reasonable future time
• It's quite unmaintained (containing lots of TODOs unaddressed since a long time) and, as thus, doesn't offer a lot (no true lists, not true subscripts/superscripts, no internationalized smart quotes, no tables, no maths, no raw code extension, etc.). Some of these could be addressed now, but is the effort worth? (when there are alternatives).
• It's just some uncompleted sort of mapping between the Pandoc AST and SILE commands (but see further below)
• Maintaining it would impose efforts on both the Pandoc-related side (when the AST evolves, which it does at times) and the SILE side (to reflect those). Moreover, synchronized efforts are always risky in open source projectq with limited involved developer manpower.
• All this being considered:
  • It shouldn't IMHO be part of the SILE core distribution - it's a barely working impediment.
  • At best, it could be turned into an external 3rd-party package (but there are alternatives, and see also further below).

This being said in good faith, do not misunderstand me, the very idea was clever. Especially the "mapping between the Pandoc AST and SILE commands" - This is what made me think having Pandoc in the loop is indeed quite unavoidable for some things: whatever efforts we could do to improve Lunamark for the "native" route, it's quite probably (and reasonably fair) that it will never fully cope up with Pandoc's myriad of options and extensions... And that working something out directly from the Pandoc AST could be worth trying, alleviating the need for a specific build of Pandoc: hence the "alternate" pandocast approach in my markdown.sile work. It's not perfect: It still naturally imposes efforts when/if the Pandoc AST evolves, but at least it's on one side only.

Rationale for keeping ('cause there must be one, indeed interesting)

My above-mentioned "markdown.sile" solutions, be it under the form of an overhaul of the "native" Lunamark-based reader or of the Pandoc AST parsing route, both generate directly a PDF from a Markdown file provided to SILE. The approach here, generating some kind of SIL-language intermediate output - Pandoc being just a converter here - allows one to easily tweak the result before processing it with SILE.

This being said, a nicer option IMHO (which may be generalized to other format inputters) would be for SILE to be able to output its own AST, in SIL or XML (= AST dumping and round-tripping - I might comment further later on the idea, for a glimpse of what it could be see, see this discussion and as an example of what it could be used for, see these tests. If it proves doable, that what I'd prefer actually, if efforts are to be involved in such a direction...

Sorry for that long text, but I hope I am not walking on eggshells and this proposal makes its points decently and fairly.

EDIT: BTW this would likely Close #413

[alerque]

This might happen someday, but not soon. I could go point by point why I think you've misunderstood the package and entire workflow I use, but this isn't some "barely working impediment", it is something I've used in production for several hundred publications. Since I maintain it, and since it doesn't block any other workflows (i.e. markdown.sile or other routes), and because nobody is forced to load the module, and since it also brings in no dependencies to compile or install SILE, I don't see any harm in leaving it be until there is a backwards compatible replacement or most projects that use it in production are frozen.

I agree it isn't necessarily the best path for somebody just starting out with SILE (at least not unless my Pandoc writer gets upstreamed). For those folks markdown.sile is probably the best place to start. This could theoretically also be moved to CaSILE, but frankly the reason I put it here in the first place still applies: I still want to see the Pandoc writer upstreamed and this being available in released versions of SILE will make that much easier.

Hence I'm going to decline this for now. I encourage further work on other workflows too, but this one is neither obsolete nor purely experimental.

[Omikhleia]

Noted.
I don't think I've misunderstood the package and (its) entire workflow.
(But my point of view remains that it has nothing to do in the core distribution and should be a 3rd-party package, whether or not Pandoc gets it at some point, -- and CaSILE could use it too, as a dependency. It's not true it freezes anyone if it's no longer in the core distribution.)