Tracking task: CLI demos should not be lukewarm on similarities to Jupyter demos

[pgunn]

Right now the CLI demos and the Jupyter demos occupy an unfortunate middle ground in terms of similarity - because they (mostly) are the results of a fork that happened a long time ago, they mostly work on the same data but have divergent parameters, and consequently get different results.

Users occasionally expect them to produce the same results and are confused. There's no urgency with addressing this (and we could reasonably decide it's not a problem), but we could instead see this as an opportunity to do one of two things.

Path A: Adjust the CLI demos to simply match, results-wise and parameter-wise, the Jupyter demos, and commit them to always do so in the future (so long as it's feasible; if it ever becomes not so, revisit this decision). Document any technical process involved.

Path B: Adjust the CLI demos to differ enough from the Jupyter demos that it's clear that users should not expect them to produce the same results. Have the CLI demos work on distinct datasets that the Jupyter demos don't look at.

Both of these have plusses and minuses. With the first, it becomes very clear to the demo how they'd make CLI versions of any Jupyter workflow (although maybe we could just document that). With the second, we get to showcase more data and don't have any messy data sync commitment. I lean mildly towards path B provided we document the process of making CLI versions of the Jupyter workflow.

Note that in the longer term, we intend for the Jupyter notebooks (and a lot of the GUI functionality) to land in a separate conda package that will be an optional install.