Make `ParserRegistry` pluggable

[agoose77]

So that other document types can be supported

[bollwyvl]

This is a splendid architectural move.

For things that are strictly JSON compatible (without internal string-banging like link parsing), JSON-LD can make this very declarative and portable, and is probably worth a special case (and the runtime dependency). Many of the declarative transform definitions can be made to work with js/py implementations.

Notebooks, of course, will always be special. A couple years back, i made a strawman JSON-LD context, but a number of newer JSON-LD 1.1 features like @nest, explicit cell ids, etc. will make this more robust today.

I think the notebook parser might be a few parsing phases, which can each access the prior levels of extracted content:

• a structural phase (hoisting the overall structure and well-defined metadata like kernel info)
• a markdown phase
• a kernel language phase
  • an nearly.js grammar can be used more-or-less directly by lark, could likely be written for at least most language's import/export semantics
  • another path is the LSIF... at some point or another, jupyter-lsp will support it
• an output phase
  • might have more markdown, but some images have embedded metadata, more JSON, widgets :yum: , etc.

Tabular data (whether in files or mime outputs) might need a little help, such as with JSON table schema, which pandas and the lumino data grid can produce/consume directly, respectively. I guess this is another place that could be pluggable.