Make code extractors and replacements modular

[krassowski]

This is a small step towards #191. I would postpone any major refactor until the JupyterLab 3.0 with the pip-based extension system ships, which seems that could change how we plan things a bit.

Pros:

• makes the code organisation a bit more sane (so that the different IPython extensions are not mixed together),
• fixes an %%html --isolated magic bug (thanks to new tests!)
• adds support for extraction of SQL from %%sql magics
• provides tentative tokens for extending the transclusions:
  • I am not sure if having two tokens (as implemented here) rather than one large "TransclusionsManager" is the way to go in the future; it is, however, the way to make some progress on a topic that no one wanted to tackle for some time and to reduce technical debt; we can change the API in the future.

Cons:

• it introduces an interface which we already plan to evolve and possibly break

Checklist

• Add ILSPCodeExtractorsManager token
• Add ILSPCodeReplacementsManager token
• Reorganise transclusions:
  • split the defaults into two packages:
    • jupyterlab-lsp:extractors-ipython, scope extractors for IPython built-in magics and expressions only
    • jupyterlab-lsp:extractors-rpy2
  • implement jupyterlab-lsp:extractors-ipython-sql to support As a user I would like to Highlight my SQL code syntax in JupyterLab jupyterlab/jupyterlab#8879 (not an IPython built-in)
• Document both the tokens
• Maybe implement host_inclusions as proposed in Formalize and extend language transclusion #191 (would benefit SQL!)

Chores

• linted
• tested
• documented
• changelog entry

[krassowski]

IPython-SQL has a connection concept which can be set per each cell or via line magic. It would be nice to be able to extract it and pass it to the virtual document so that it can be passed on to the language server during document initialization.