Add activation events for providing/resolving tasks (TaskProvider extension API)

[SchoofsKelvin]

This PR is related to issue #99797 and its consequent PR #99957.

This PR makes the following changes:

• Add onTaskProvide:taskType activation event whenever VS Code queries TaskProviders for tasks
• Add onTaskResolve:taskType activation event whenever VS Code needs to resolve a TaskProvider's task
• Add and implement ITaskService.getPossibleTaskTypes(): Promise<string[]>
  An async version of .taskTypes() which also checks all task definitions defined in package.json of (inactive) extensions
• Make TaskQuickPick use this new getPossibleTaskTypes()
  Task types for inactive extensions (that specify taskDefinitions in their package.json) also get listed now

Related activation events and triggers:

• onTaskProvide:taskType triggered by selecting Show All Tasks in the Tasks: Run Task's TaskQuickPick
  This is fired for every task type registered in TaskDefinitionRegistry (except for shell and process)
• onTaskProvide:taskType triggered by selecting an extension top level entry in the Tasks: Run Task's TaskQuickPick
  This is fired for just the selected task type
• onTaskResolve:taskType triggered by trying to resolve a task, if it has a type defined

---

I recently added a TaskProvider for my extension, and noticed that in certain cases, it couldn't be resolved. After taking a look, it seemed to be caused by the extension not being activated yet, hence not having registered the TaskProvider. With this PR, extensions can now add a proper activation event to deal with providing/resolving their tasks.

I noticed while working on this that #99957 made it that extensions can activate on onCommand:...runTask or even * instead. This PR provides more specific activation events, instead of having to rely on the aforementioned events.

Another possibility that I have thought about but decided against:
Since we can use taskDefinitions (TaskDefinitionRegistry) to figure out which extensions will (should) provide TaskProviders for which types, we can automatically start an extension when we need to provide/resolve using such a provider. The taskDefinitions would basically also register the extension for the appropriate onTaskProvide/onTaskResolve activation events.
The same could be done for commands, since similar to taskDefinitions we can access commands too, including from inactive extensions. Since this auto-registration isn't actually the case for commands, I assume it shouldn't be the case for task definitions either.

[ghost]

All CLA requirements met.

[SchoofsKelvin]

It's been almost 2 months since I created this PR. Did I miss a step about submitting it somewhere?

[alexr00]

@SchoofsKelvin I haven't had a chance to take a look at the PR yet. I will try to get to it this month.

[SchoofsKelvin]

It's been a year since I opened this PR, any news?

I've rebased (on main) to resolve merge conflicts and retested it two days ago, and in the meantime the PR checks have passed.

[meganrogge]

Hey @SchoofsKelvin sorry for the delay. Unfortunately, it looks like there are quite a few conflicts now to deal with before I can review the PR.