For #91510
Switching TS versions is fairly uncommon, so repurpose the status bar entry to have additional project commands in it (including the ability to switch TS versions)
* Expose importModuleSpecifierEnding to typescript-language-features
* Add default `auto` setting
* Use string 'auto' for auto setting
* Work with TypeScript 3.8
* Let extensions prepopulate the issue reporter title and description
Fixes#91028
Adds two new optional arguments to the `vscode.openIssueReporter` command: `issueTitle` and `issueBody`. These are taken using an options object and are used to pre-populate the native issue reporter fields
Hooks up these fields for TypeScript's report issue prompt. We use this to post the most recent TS Server error stack
* Extract duplicate command id to constant
* Log version directly instead of prompting users for it
- Make sure that `TypeScriptVersion` is immutable by getting and caching `apiVersion` on init
- Only show dot next to currently active version if both path and api versions match
For #13953
**Problem**
We'd like to show project wide diagnostics, however at the moment TS server is single threaded. This means that computing all these diagnostics would interrupt other user operations such as completions.
Right now, our advice is to use tasks to get around this limitation (since tasks always run as separate process) however few people actually use tasks.
**Change**
This change adds an experimental `tsserver.experimental.enableProjectDiagnostics` setting (default false) that makes VS Code spawn a separate TS Server that is only used for computing diagnostics. This should help keep the primary syntax server responsive while letting the diagnostics server churn away at project level diagnostics
**Why experimental?**
- We are comporting too many diagnostics. This is bad for larger projects. I don't think TS provides the right APIs to know which files we actually need to request diagnostics on when a file changes.
- This hasn't been fully extensively tested to make sure it plays nicely with feature such as automatic type acquisition or in complex workspace with multiple projects
Currently extensions like TS have a dev dependency on the `"vscode"` package. This pulls in a copy of `vscode.d.ts` that we end up using instead of our local `vscode.d.ts`.
This change uses the `paths` `tsconig` option so that we use our local `vscode.d.ts` instead of the one from `node_modules`
