Notes on using Lonboard in a remote (esp JupyterHub) environment

I was pairing with @wildintellect on debugging why Lonboard wasn't working in a JupyterHub environment and we came up with a couple notes.

In particular, it's very easy to get lost in environments. Generally a JupyterHub server has _at least two_ Python environments. There's a _server_ environment in which JupyterHub itself is installed and from which it's launched, plus one or more user _client_ environments. As far as I can tell, a Jupyter widget needs to be installed in **both** environments, and presumably those versions must match.

The widget installed on the _server_ environment is necessary to provide the JS bundle as part of the webpage the user loads, while the widget installed on the _user_ environment is necessary so the Python model works.

- Are there ways to provide helpful errors when no JS code is found? Only a JS console error is produced. Is there some way to catch that and provide a more helpful error to the user?
- Is there a good way to validate that the frontend and backend versions of lonboard match?

Aside from lonboard-specific tasks, I wonder if there are tasks that JupyterHub could do that would simplify the loading of widgets so that they _don't_ need to be separately pre-installed on the server. Additionally, ensuring versions match between the user's environment and the global server environment sounds _messy_.

I've noticed that Colab handles this problem quite well (I think it's with their [googlecolab/colab-cdn-widget-manager](https://github.com/googlecolab/colab-cdn-widget-manager) project). In particular, the first time that a widget is attempted to be rendered, the JS code for that widget is _dynamically_ added to the page. This means that

```
!pip install lonboard
from lonboard import viz
viz([])
```
will _just work_, even without restarting the kernel or reloading the browser tab, because the JS side doesn't need to exist already when the Python side is created.

cc @batpad

Start by reproducing Lonboard in a remote JupyterHub setup with separate server and user environments, then compare the installation and version behavior with Colab's colab-cdn-widget-manager. A complete outcome would need a decided approach for missing JavaScript errors, frontend/backend version matching, or dynamic widget loading; the issue does not name files or tests.

Written by the indexing model from the issue text.