Language Runtime enums must exist in too many places

[jmcphers]

The enums associated with the Language Runtime API need to exist in the vscode.d.ts type definitions, so extension authors can build on them.

https://github.com/rstudio/myriac/blob/87d043fa70b8734129f733865d420d9f31fca04d/src/vscode-dts/vscode.d.ts#L16447-L16457

Hygiene rules ensure that types that exist on the external API must also exist on the extension host, so we have to copy this to extHostTypes.

https://github.com/rstudio/myriac/blob/87d043fa70b8734129f733865d420d9f31fca04d/src/vs/workbench/api/common/extHostTypes.ts#L3899-L3909

Other rules forbid the importing of any types from vscode API or extHost (which represent the extension host process) into the core/contrib code. So we have to define the enum a third time there for use inside the core.

https://github.com/rstudio/myriac/blob/87d043fa70b8734129f733865d420d9f31fca04d/src/vs/workbench/contrib/languageRuntime/common/languageRuntimeService.ts#L33-L42

It feels like there ought to be a way for us to reduce this to two type declarations, or even one.

[kevinushey]

Looks like these have already gotten out-of-sync in the top-level positron.d.ts file:

https://github.com/rstudio/positron/blob/adf3167ed747ca0db1d16a133ad01fa1da5825c2/src/positron-dts/positron.d.ts#L43-L52

https://github.com/rstudio/positron/blob/adf3167ed747ca0db1d16a133ad01fa1da5825c2/src/vs/workbench/services/languageRuntime/common/languageRuntimeService.ts#L149-L158

https://github.com/rstudio/positron/blob/adf3167ed747ca0db1d16a133ad01fa1da5825c2/src/vs/workbench/api/common/extHostTypes.ts#L3995-L4005

https://github.com/rstudio/positron/blob/adf3167ed747ca0db1d16a133ad01fa1da5825c2/src/vs/workbench/api/common/positron/extHostTypes.positron.ts#L41-L51

so having a solution here would be helpful.

The approach I took for language runtime events was to auto-generate the interfaces from a single source of truth:

https://github.com/rstudio/positron/blob/main/positron/scripts/generate-events.ts
https://github.com/rstudio/positron/blob/main/positron/events.yaml

Would a similar approach be worth considering here?

[jmcphers]

This might not be as bad as I thought, because it turns out that sometimes you don't want or need these to all be identical. For example LanguageRuntimeState now has a different set of states in the core code than it does on the extension side, because some states are specific to the core side of the implementation.