[Feature] API for other extensions to register their own kits

### Request Overview

We develop the [Qt Extension for VS Code](https://github.com/qt-labs/vscodeext) (`qt-cpp`). Our extension finds the installed Qt versions and creates a CMake kit for each of them.

Right now the only way to do this is writing directly into `cmake-tools-kits.json` or `.vscode/cmake-kits.json`. But CMake Tools also writes to these files, so we keep running into synchronization problems. For example when `scanForKits` runs, it rewrites the whole file from what it has in memory ([kitsController.ts#L588-L616](https://github.com/microsoft/vscode-cmake-tools/blob/86b8f7c7/src/kits/kitsController.ts#L588-L616)), so kits that we just wrote can get lost. We tried to work around this with write queues and by remembering which kits we generated before, but it is still not reliable, because we can never know when CMake Tools reads or writes the file.

It would be much better if there was an API to register kits instead of writing files. Something like:

```ts
export interface KitProvider {
/** Fired when the kits of the provider change (Qt installed/removed etc.) */
onDidChangeKits: vscode.Event;
/** Kits for one folder, or global kits when folder is undefined. */
provideKits(folder?: vscode.WorkspaceFolder): Promise;
}

export interface CMakeToolsApi {
// ...
registerKitProvider(providerId: string, provider: KitProvider): vscode.Disposable;
}
```

The kits from a provider would be shown together with the other kits but never saved into `cmake-tools-kits.json`. When the provider is disposed, its kits disappear. This way each extension owns its own kits and nobody has to touch the files of the other one.

This is similar to how other VS Code APIs work (`TaskProvider`, `DebugConfigurationProvider`) and it would also be a more general solution than the hard-coded `cmake.cmakeProviderExtensions` list.

We would be happy to help with the API design and the implementation.

### Additional Information

_No response_

Start with kitsController.ts around lines 588-616 and review how kits are scanned and persisted in cmake-tools-kits.json and .vscode/cmake-kits.json. Design and implement the CMake Tools API registration point so provider kits appear with other kits without being saved, update when providers signal changes, and disappear on disposal; add coverage for these behaviors if the existing test structure identifies a suitable location.

Written by the indexing model from the issue text.