Separate existing plugins into sub-packages about jupyterlab-markup

[bollwyvl]

Yeah not scared of multiple conda packages, especially if they are all versioned together (which I recommend). It would be key, however to have a few "presets," e.g. "everything that works on hackmd/hedgedoc without a rendering server" so that one doesn't have to go shopping. The existing issue (number escapes me) about documenting which plugins are actually _used_ is probably a hard blocker on this. In a notebook, I see that as metadata. In a document... I guess an html comment? You'd then need some way to see in UI that you are missing stuff. Though probably a separate issue, as we break stuff up, in-UI discoverable, per-plugin syntax documentation and examples will become even more important... and eventually some kind of language server. Those two features probably warrant a single notebook/editor toolbar button that opens a menu listing all the plugins.

[agoose77]

Yes, this is certainly part of a bigger question. My thought is that this is something we stick in the notebook metadata, under some key for jupyterlab-markup. In documents, at least for markdown, we could stick it in YAML frontmatter?

---
markdown-it-plugins:
  - anchor
---

This would probably want us to use the npm package names for the syntax rather than our jupyterlab names, so perhaps the plugin interface should be extended to define an LSP key (or keys, in the case that one plugin does several things).

[agoose77]

I've given this more thought recently w.r.t executablebooks/jupyterlab-myst#38

Right now we enshrine a random subset of Markdown-it plugins as "core", when in reality there's no strong motivation for this. I think long-term we should use the extras mechanism for this instead.

[bollwyvl]

also happy to give the lerna-fication of this a go in a PR.

for big monorepos with demos + docs (#65), i've often ended up adding a top-level dodo.py to handle orchestrating all the intermediate generated objects and making releases reasonable...