Optional automatic upgrade for new client config features in existing user-defined language server definitions

Quite a few new LSP4IJ features are being added via client configuration, but the discoverability of those features for existing users is quite low because the defaults for these features generally favor backward-compatibility unless explicitly configured/enabled. While the preferred enablement defaults are being added to the respective bundled language server definition templates, users with existing language server definitions do not benefit from these changes unless users know to update the client config JSON. This will continue to be a growing issue as more and more new features are added via client config.

In my own plugin that uses LSP4IJ to improve the editor experience for JavaScript/TypeScript/CSS in Community Edition IDEs, I've implemented automatic upgrade logic to add newly-defined client configuration properties to existing language server definitions. This upgrade logic is very careful not to change any explicit end user client configuration. Basically it does the following:

1. Loads the active client configuration JSON for a defined language server definition into memory as a raw Map.
2. Loads the template client configuration JSON for the associated language server definition template into memory as a raw Map.
3. Recursively reconciles every leaf property in the template client configuration against the corresponding property in the active client configuration.
4. If a template property does not exist in the active configuration and has never been added previously based on a retained "memory" of previously-upgraded properties, it is added to the active configuration and to the memory.

In this way, if a client configuration property is added to an active client configuration and the user later changes its value or even removes it from client configuation, it will not be updated again because it will have been denoted as added previously.

In my plugin, this happens unconditionally, but if added to LSP4IJ, it would make sense for this to be conditional. This would require the addition of two new fields to the persisted UserDefinedLanguageServerDefinition configuration:

• clientConfigurationUpgradePolicy - determines whether/how automatic upgrade of client configuration is performed for the language server; values are PROMPT, ALWAYS, and NEVER; defaults to PROMPT, but can be easily switched to ALWAYS or NEVER via a Don't ask again checkbox in the prompt dialog or in the user-defined language server definition panel.
• clientConfigurationUpgradedPropertyNames - the set of fully-qualified previously-upgraded client configuration property names; this is the "memory".

With these changes, before LSP4IJ starts a language server based on a user-defined language server definition, it would do the following:

• If clientConfigurationUpgradePolicy == NEVER, it just starts the language server.
• Otherwise it performs the steps above to determine the missing properties without applying changes. If if finds missing properties:
  • If clientConfigurationUpgradePolicy == ALWAYS, it applies them, notifies the user of the exact properties that were added, and starts the language server.
  • If clientConfigurationUpgradePolicy == PROMPT, it prompts the user as to which should be applied, applies any that were selected and notifies the user of the exact properties that were added, and starts the language server. Note that all missing properties are added to the memory whether or not they were added to avoid repeated prompts for properties that were not selected.

Again, aside from the small amount of work to make it optional, this is something I've already implemented in my own plugin, so it would really just be a port of something that already exists.

Let me know if you think this would be valuable or not for all LSP4IJ users and, if so, I'll be happy to implement it and get a PR going.

Start by locating UserDefinedLanguageServerDefinition and the code that starts a language server; review the client-configuration and template handling described in the issue. Compare it with the author's existing plugin implementation, then define persisted policy and property-memory behavior, prompt and notification flow, and tests covering NEVER, ALWAYS, and PROMPT.