Support federated serverlite extensions

[bollwyvl]

Problem

At present, a JupyterLite pretty much must include all of the kernels, exactly the contents/settings extensions provided etc. It's also basically not possible to add new serverlite extensions without forking or going through the PR process here.

Proposed Solution

At extension build time adopt either:

• exactly the jupyter labextension build toolchain,
  • we might be able to get by with "requiring" (as in, might build, but not run without) package.json#/jupyterlab/sharedPackage pointers to jupyterlite/server
• an extension-by-subclass of that machinery for jupyter serverlitextension build (that is very long)

At configuration time, either:

• use exactly federated_extensions
• use a very similar federated_serverlite_extensions

At runtime:

• use the config
• actually read package.json

Additional context

As a stopgap, it was proposed elsewhere to offer a way to specify a mock server response via OpenAPI to provide enough server information to trick an existing, useful labextension into working, e.g. jupyterlab-videochat.

[bollwyvl]

from #348: We should probably start looking into #104.

Agreed, (unfortunately, as this looks very cool).

More broadly, bespoke kernels will end up being the "long pole" for size, build time, and complexity: for example, pyodide is already quite complex, and will get more complex on #310.

For users, this would play out like:

• each kernel build/config chain would end up being a separately-installable pip package which can bring its "core" distribution, extra build steps and dependencies, etc.
  • each (e.g , jupyterlite-lualite) would depend on a new jupyterlite-core package
• the jupyterlite metapackage would then depend on the "grandparented" packages (jupyterlite-jslite, jupyterlite-ipyolite)