feat: Add enabled user setting to LS sync

Description

This change adds configuration options for enabling/disabling two features: code completion and Duo Chat.

The code now reads these settings from the VS Code configuration and passes them to the language server FeatureStateManager. In the language client wrapper, new properties are added to track whether these features are enabled (defaulting to true), and these settings are included in the client configuration sent to the server. The test file was also updated to include these new configuration options in the test cases.

On a user enabling/disabling code suggestions or chat in the settings; this will update the FeatureStateManager in the language server and send a notification to the client.

Related Issues

Resolves Migrate `UserDisabledPolicy` for CS to the LS i... (#1633 - closed) and is a part of this work: [VS Code]: Feature State Diagnostics Section (#1760 - closed).

How has this been tested?

1. Apply this diff to language_client_wrapper.ts:

diff --git a/src/common/language_server/language_client_wrapper.ts b/src/common/language_server/language_client_wrapper.ts
index af3e5d83..ae60ca0f 100644
--- a/src/common/language_server/language_client_wrapper.ts
+++ b/src/common/language_server/language_client_wrapper.ts
@@ -123,6 +123,7 @@ export class LanguageClientWrapper {
     );
 
     this.#client.onNotification(FeatureStateChangeNotificationType, async params => {
+      log.info(`Received feature state change notification: ${JSON.stringify(params, null, 2)}`);
       this.#featureStateManager.setStates(params);
     });
 

2. Run the extensions locally npm run watch:desktop
3. Open the logs for GitLab Workflow
4. Open settings for GitLab Workflow Workspace settings and toggle the Code Suggestions Enabled and Duo Chat Enabled on and off
5. Check the engaged checks of the LS notification changes in the logs and it will show that user disabled a feature

• If src/browser or src/common has been modified, please consider interoperability with the Web IDE. See Running the Extension in WebIDE.
• Consider an end-to-end test for significant new features that aren't covered by integration tests.

Screenshots (if appropriate)

What CHANGELOG entry will this MR create?

• fix: Bug fix fixes - a user-facing issue in production - included in changelog
• feature: New feature - a user-facing change which adds functionality - included in changelog
• BREAKING CHANGE: (fix or feature that would cause existing functionality to change) - should bump major version, mentioned in the changelog
• None - other non-user-facing changes