R: configure default runtime

[sharon-wang]

Implementation Summary

Create an equivalent option to python.defaultInterpreterPath for R.

A new option will be added to a default path to an R binary which will be used for newly opened workspaces. The user can configure this option via the Settings UI or via the user settings.json directly. As such, these settings will be applicable at the workspace and/or user scopes, and can be preset by a workbench admin via positron-user-settings.json.

add positron.r.interpreters.default settings option

• a String; a single path to an R interpreter binary
• Draft description: Path to default R binary to use when extension loads up for the first time, no longer used once an interpreter is selected for the workspace.
  • this description reuses the Python option python.defaultInterpreterPath's description
• Default: null; or R (which R) -- this would be consistent with python.defaultInterpreterPath which has python as the default

Mockup of Settings UI

Difference between this issue and #2659

This issue is distinct from #2659 in that this issue is about establishing a default interpreter for any general workspace a user opens, whereas #2659 focuses on specifying a default interpreter for a specific workspace.

this issue	issue #2659
if I open a workspace I have not previously opened in Positron, I want interpreter /path/to/my/interpreter/4.3.0/R to be used by default, until I change it to something else	when I open my workspace my-data-analysis, I want to ensure that the interpreter R 4.3.0 is the affiliated runtime that is started each time

Implementation Considerations

What if a user specifies invalid paths, the interpreters or directories don’t exist, or something else is wrong with the user’s input in settings?

• If any of these are invalid for any reason (i.e. broken path, does not exist), we will indicate as such in logs and/or via Notification toasts at the time of discovery, as there isn’t very robust input validation in the Settings UI.
• May need some additional UI/notifications to cover the case where this causes discovery to find nothing. “Could not find any interpreters included in the setting python.interpreters.override. Would you like Positron to try again, without the setting?”
  • We have a Positron core toast “no interpreters found”, but maybe not for Python or R yet

What if a user has interpreter includes, excludes AND overrides specified?

• Overrides will take precedence over any specified includes and excludes, so if a user has all three specified or one of includes/excludes specified along with overrides, we will only use the overrides.
• How to surface this to the user?
  • INVESTIGATE: can we update the setting descriptions for includes/excludes to indicate that the override option will take precedence when the override option is set?
  • include in the setting description that includes/excludes will be overridden by overrides; and in overrides description, include that it will replace any specifications in includes/excludes.

Example scenario

• Possible Interpreters:
  • /path/to/a/python/1
  • /path/to/a/python/2
  • /path/to/a/python/3
  • /path/to/pyenv/python/1
  • /path/to/global/python
• Options
  • exclude: /path/to/global/python, /path/to/a/python/3
  • include: /path/to/a/python/2
  • override: /path/to/a/python/1
• Result of discovery:
  • /path/to/a/python/1

How does the default path option work if the workspace-level setting is configured for a collaborative project?

• Paths to binaries are specific to a machine. For collaborative projects that are accessed on various desktop machines, the default path option doesn't really make sense as each person could have R installed in different locations. For a managed environment, the path to R will be configured by an admin on the server/in a container, and as such will be consistent across users who access Positron via a web interface.
• We can have handling that tries the default path and if it doesn't exist, then we fallback to which R