Add Positron Runtime Service to store session-scoped Language Runtime state

[jmcphers]

Positron's Language Runtime Service is currently ephemeral. It stores no data of its own and doesn't persist between browser sessions (or reloads). Any information about the state of a language runtime that needs to persist between browser sessions must be handled entirely in the language pack. This is the reason that the Jupyter Adapter has a bunch of "reconnect" logic it runs to discover active kernels and then inform Positron about the state of active kernels after a reload.

We should consider implementing a persistent runtime service that gives us a place to store session-scoped information in a runtime-agnostic way. For example, it could:

• Store information about any runtimes that are active in the session, freeing the language packs themselves from having to solve this problem.
• Store metadata about the runtime's current state, for example, whether it is busy and what its current working directory is. Tracked in Reloading with busy runtime looks frozen, breaks LSP #1243
• Store information about ongoing computations, for example a queue of statements that needs to be submitted to the runtime but that hasn't been submitted to the interpreter yet. Tracked in Queued commands are lost after reloading #1220.
• Store computational results (plots, models, textual output, etc.) that were generated while no browser was connected, and need to be displayed to the user the next time a browser is connected. Tracked in Output from R and Python is dropped during a reload or browser tab close #4577.
• Optionally become a standalone process host alongside the PtyHost (currently the PtyHost is the process supervisor for kernels), so kernels would run under the RuntimeHost instead of the PtyHost.

In the case of language runtimes backed by Jupyter kernels, for example, the service would add a layer of abstraction between the front end and the kernel. It would serve as the kernel's client, and would be responsible for queuing work for the kernel and receiving all the kernel's output and forwarding it to the front end when there's one connected (and queuing it when no front end is connected).

There are some tradeoffs between the flexibility of having language runtimes manage things themselves and the advantages of a more homogenous but centralized solution, but it seems inevitable to me that we will need some kind of session-scoped service in order to have a robust implementation of Positron inside a browser-based environment like Posit Workbench.

[jmcphers]

Will tackle along with #1625 to help address #1617.

[jmcphers]

In the last year, basically everything that this issue was originally intended to cover has been addressed; I've filed followup issues for the remaining items.

We now do track state of each running session at a service level instead of expecting the language packs to do it. That work was accomplished in #1625.

The remaining work is basically to add a supervisory layer that will keep R and Python running headlessly while Positron's front end and extension host are disconnected. That work is tracked in #1220, #1243, and #4577.