Export custom comm message types and structure in Positron API

[jmcphers]

Positron contains a number of custom communication channels, each of which defines its own protocol for frontend/backend communication. These generally represent UI elements, such as the Environment pane, a plot, a data viewer instance, etc.

For example, Environment pane exchanges messages with its back-end counterpart using strongly typed data structures, which currently live here:

https://github.com/rstudio/positron/blob/main/src/vs/workbench/services/languageRuntime/common/languageRuntimeEnvironmentClient.ts

While this is an appropriate source of truth for the data structures while they are evolving rapidly, at some point we need to define the protocol for each comm such that third parties can implement their own backends for these UI elements. That probably means that they need to be represented in positron.d.ts in some way.

[jmcphers]

We currently have some infrastructure that does code (and type) generation for Positron global events (see events.yaml), but it isn't used much since, unlike RStudio, Positron's client/server communication is typically scoped into comm channels of the kind we're talking about here.

As we've added and refined comms over the last couple of months, enough patterns have emerged that I think we could codify them effectively in YAML. Each comm has:

• an ID
• a set of events that carry data payloads (almost identical to the Positron global event list)
• a set of RPCs that are like events but have a send type as well as a return type

From the YAML we could generate the typings in positron.d.ts as well as boilerplate client code, and possibly also Rust types in amalthea.

[seeM]

We could probably do this for Python pydantic models too. I started on that in #865 but decided to close it until we formalized our comms a bit more

[lionel-]

#1942 laid out the ground work for this formalisation.

[jmcphers]

One way to do this would be to factor the implementation of the comms so that the actual RPCs are not part of the Positron API, and only the API surface is. This approach is detailed in #4997.