Plot specs and views as a separate project

[danielballan]

A thought I had today is, when we follow through on #65 we will have three layers:

1. An abstract description of a Figure, Axes, and various plot marks (lines, images, etc.) that work with multiple Views (Jupyter, Headless MPL, Qt MPL, soon plotly and bqplot, etc.) that only know "Here's the function I call to get an update" and "Here is the signal I subscribe to listen to when an update is available." No bluesky concepts here.
2. Shims that adapt (1) to BlueskyRun, hooking BlueskyRun's signals into the generic signals implemented by (1).
3. Models that, given a BlueskyRun or an observable list of them (depending on the model), update a Figure or a list of them (depending on the model). The RecentLines and AutoRecentLines models are examples of these. We provisionally call them "plot builders." They are tightly coupled to (2) and to the concept of BlueskyRun, and they provide a user-friendly interface tuned to specific use cases.

The models and views in (1) could make sense as a stand-alone project, perhaps even outside of the bluesky organization. It bears more than a little resemblance to the design of the planned "Matplotlib 4", but there is not complete overlap. These models and views encompass frameworks' UI elements beyond the "figure area" (for example, Qt or Jupyter tabbed widgets of multiple figures; or Qt or Jupyter sliders for scrolling through multi-dimensional figures). Also, as a separate, new project it could move at whatever pace we need it move at and prioritize the features that we need.

I don't think it makes sense to factor it out at this early stage, but it might make sense to do so in the future.