Prioritize affiliated runtimes; ensure that after boot, primary runtime is active

[jmcphers]

Currently, runtime affiliation with workspaces happens on a per-language level. That is, if you use R and Python in a workspace, we will separately affiliate an R interpreter and a Python interpreter with your workspace, and both will be started when you open the workspace.

However, we don't currently weight or prioritize the runtimes affiliated with the workspace. This means that even in workspaces that are primarily R based, if Python is also affiliated with the workspace, it will start up too, and take over the foreground (since Python currently registers runtimes after R).

We should remember the primary runtime that's affiliated with a workspace, and ensure that one is started first (see #1067), and that others are started in the background and don't take focus.

We don't currently ask users to identify the primary runtime; we could do that ourselves via a combination of heuristics (asking extensions to supply some kind of affinity rating derived from e.g. the project's files/type) and/or inference (noting what runtime typically has the foreground, and which one was active in the last session).

[nealrichardson]

We don't currently ask users to identify the primary runtime; we could do that ourselves via a combination of heuristics (asking extensions to supply some kind of affinity rating derived from e.g. the project's files/type)

I would think that some very simple heuristics would get you right most of the time. Certain files are always associated with one language, like DESCRIPTION, NAMESPACE, .Rbuildignore, etc. for R; requirements.txt, setup.py, etc. for Python. If you only have files from one list or another, you can assume it's that language.

Context from me: I opened an R package in Positron, no Python in it anywhere, and Positron started the Python console.

[jthomasmock]

We don't currently ask users to identify the primary runtime; we could do that ourselves via a combination of heuristics (asking extensions to supply some kind of affinity rating derived from e.g. the project's files/type) and/or inference (noting what runtime typically has the foreground, and which one was active in the last session).

I think we should have a way for users to explicitly select a primary runtime at the project-level. This could be set by default when using the New Project flow and selecting a specific language. For "folders" or other existing projects, we could have a workspace-level option to set this manually and eventually incorporate it into the richer runtime selector tooling post RC.

The Python extension has a default interpreter and several additional manual fields for various language runtime managers:

Python: Default Interpreter Path

Path to default Python to use when extension loads up for the first time, no longer used once an interpreter is selected for the workspace. See here to understand when this is used

The R extension has a custom path setting, but not a default interpreter:

Positron › R: Custom Binaries

List of additional R binaries. If you want to use an R installation that is not automatically discovered, provide the path to its binary here. For example, on Windows this might look like C:/some/unusual/location/R-4.4.1/bin/x64/R.exe.

In addition to on-disk heuristics such as requirements.txt, lockfiles, renv, etc, it would be nice to eventually track frequency and duration of runtime use.

IE there could be two rich heuristics:

1. After we have multi-session, how many runtime X are started, how many runtime Y are started, etc. These could be both language (R or Python) and version (4.4 or 3.12, etc)
2. Duration, aggregate across language and version?

[jennybc]

Related to #2659