Allow additional plugin examples to be registered

[bollwyvl]

Problem

Some extensions are themselves extensible (e.g. jupyterlab-markup, jupyterlab-lsp), and might like to advertise this in a more declarative way, especially in documentation/demo settings (e.g. #16).

Proposed Solution

Offer a new launcher card per template.

Extend the public api proposed on #49 to allow registering new plugin templates, with a few options including a documentation markdown file.

Additional context

Types

export interface IPluginExample {
  title: string;
  description: string;
  src: () => Promise<string>;
  doc?: () => Promise<string>;
  icon?: LabIcon;
  filename?: str;
}
export interface IPluginPlayground {
  addExample(example: IPluginExample): void;
}

[krassowski]

Dreaming a step further: plugin examples in notebooks. Not sure if we would want a kernel or just a magic for IPython.

[bollwyvl]

Right. I think the lite js kernel play is right, first. I don't think ipython, or even pyolite, is a particularly productive host for extensions, as the startup cost is huge. Even with the js kernel, there would be some cognitive dissonance on what's happening in an iframe/worker vs the main app. A number of councilfolk have expressed willingness to upstream lite, or something that enabled it: basically, we would need jupyterlab/services to allow for more sources of kernels (and maybe contents), and since kind of first party serviceworker, which is semi-terrifying.

[bollwyvl]

But yeah, long con `jupyter labextension build untitled.ipynb` sounds real tasty... basically nbexplode a bunch of metadata/cells into files. Jss would be a good target for css, as it's valid JSON. Images could be handled by attachments, if they weren't so limited (I think just markdown, no post-hoc management, and no human readable name). Tsx wouldn't be very fun.