Add support for plugin options

[agoose77]

@bollwyvl I'm thinking that the solution here is a per-plugin options schema that is aggregated by the jupyterlab-markup extension. I'm not familiar yet with the settings configuration; do you think this is the right approach?

[bollwyvl]

Unless you do a bespoke UI, it would be hard to have "one setting pane to rule them all", and the user getting any kind of support. on jupyterlab-lsp, we went with each feature getting its own settings schema, and even there, given the composite nature of many of the, it's very limiting. this has lead other tools (e.g. vscode) to adopt crazy-pants notation like "some.deep.path": ["value"] which make any sort of external assessment of it (e.g. JSON pointer) of these structures all but impossible.

anyhow: i think it's entirely reasonable, given that each plugin is in fact a full jupyterlab plugin, for them to have their own settings, and be able to handle them however the heck they want. the settings need to actually be fetched with an individual REST call, so it could be, much like with jupyter-widgets, that the the register pattern should accept a Promise<MarkupExtension> (or whatever the heck we built).

But again... much like with extensible markup (that doesn't have a dedicated way to self-document even what plugins are in use) in the first place, if the configuration of tiny pieces of markup is entirely controlled by the user, the chances of it reproducing close to faithfully anywhere other than where it was written else start going down pretty fast.