Support other loader mechanisms?

Cool stuff!

We've had a lot of fun with `requirejs` over the years, and there's a lot out there that uses it (sometimes due to us fighting for upstreams to publish UMD), but ES modules are supported in all browsers where jupyterlab will otherwise work, work really well, and don't require (har!) learning a different pattern than all the other stuff out there. I want the hours of my life back dealing with `requirejs` shims, and paths, modules, etc.

Anyhow, in the interim, perhaps a `jlab-dynext-core` which handled the `Token` resolution, a `jlab-dynext-requirejs`, and a `jlab-dynext-esmodules` for The Future (Today). Indeed, once Lab 2.0 drops, looking to 3.0 it would be interesting indeed to see if https://github.com/pikapkg/snowpack could provide a standards-forward approach to get the whole shooting match out of bundlerizing on the end user's machine, and likely making local development more pleasant, to boot.

Anyhow: of note on the extension editor feature: we're still plugging along on https://github.com/krassowski/jupyterlab-lsp and would very much like to see a typescript/javascript language server be part of that editor experience. In this _particular_ case, we may well want a language server wired right into Lab so that we can override file-discovery-based things (eek, `node_modules`) to pull stuff directly off the working lab, rather than delegating to node over a websocket...