Add architecture diagram to README or docs somewhere about jupyterlite

[jtpio]

Thanks @telamonian.

Yes for now there is one in this temp gist: https://gist.github.com/jtpio/3763af75ec8cd7bfdce86501563fef09

But it could be improved and other diagrams covering different parts could also be added (https://github.com/jtpio/jupyterlite/issues/34).

[bollwyvl]

So... as a systems enginerd, i love building diagrams (obviously) but having them purely for documentation means they get out of date almost immediately. Over on jupyterlab-lsp, we spent a bunch of effort getting them set up, but then I have shamefully been really bad at updating them while @krassowski goes off and builds 🔥 stuff. And graphviz is barely fit for purpose in this case. ipydrawio (which i want REAAAALY BADLY in jupyterlite) is better at both being a diagram and being a model. The reason I haven't PRd the initial (or any other) diagram from #34 yet is I need to think real hard about how to keep them accurate and get real value out of that model.

Another challenge we have is this architecture is best described as a delta from a reference architecture (pip -> @jupyterlab/application-top -> jupyterlab -> jupyter_server), for which there are no systems models.

Anyhow, onto testability: the initial chartjunk of ls packages/*/package.json apps/*/package.json is relatively easy, as we can check the symmetric difference of the labels without even understanding the underlying XML very much. So I can probably get something out pretty quick that would keep this up-to-date, and add ipydrawio to the docs/binder environment, and deal with dumb-old-regexen or stdlib xml parsing and xpath to be more precise.

An area of (sometimes-funded) research is turning visual representations into executable test cases #6. For example, #79, that's a relatively complex sequence diagram involving multiple re-entrance to a browser session... and it might not make that great of an explainer, aside from showing that multiple apps can reuse the contents manager.