Follow up on #61756
Two fixes:
- Avoid allowing the `_typescript.configurePlugin` to activate the ts extension non-lazily by instead using a `PluginConfigProvider`
- Restrict configurePlugin to TS 3.1.4
#54972
Instead of having a generic `Retrigger` reason, add a new field on the `SignatureHelpContext` that tracks if this was a retrigger or not. This allows retrigger for all the different trigger reasons, including invoke.
Replace the old `Retriggger` trigger reason with `ContentChange` which tracks cursor movement and text updates.
* include priority in requestItem and add to queue accordingly
* add boolean lowPriority flag to requestItem and add to queue based on that
* set lowPriority flag to optional
* send lowPriority flag from CodeLensProvider
* revert priorityFlag for provider
Introduces the concept of a re-trigger character to the signature help provider. This is a seperate set of characters that are registered with the provider. Typing a retrigger character fires a new signature help request if signature help is already showing.
#54972
Setup a baseline tsconfig for extensions to extend. This will help make sure thatof our built-in extensions are using the recommended settings for target and so on. it also reduces duplicated code and will make updating tsconfig settings easier
A successful error computation more or less signals that the server is ready and is more reliable than waiting for the projectUpdatedInBackground signal
**Problem**
In the ts server communication, canceling a request currently throws an exception. This is wrong because cancellation is not an error. It also means that we need to wrap every server call in a generic try catch to handle cancellation. There are no checks in place to distinquish a cancellation from a rea
**Problem**
We'd like to understand the types of problems users are running into when using the checkJs feature in real world code. This is not something we can determine automatically
**Fix**
The TS team has put together a short survey that will hopefully help them understand how people are using checkJS and what problems they run into. This change adds client side logic to show the survey in the following case:
- A user as opened 10 projects that have checkJS set
- And they have not been prompted to complete the survey previously
- And they have not opted out of all js/ts surveys
