Bug/Feature Request: Allow configurable error reporting levels for partial LSP compatibility

Description:

Currently, when a language server (e.g. Haskell Language Server) returns responses that include newer or partially unsupported LSP extensions (such as textDocument/inlayHint or importLens), LSP4IJ throws a ResponseErrorException and stops consuming the response. This behavior prevents the IDE plugin from continuing to provide other available services, even if most of the protocol is still compatible.

Problem:

• Strict error handling causes the entire language server integration to fail when encountering one unsupported feature.
• Users lose access to otherwise functional features (completion, diagnostics, hover, etc.).
• This is especially problematic for fast-evolving language servers (e.g. HLS) that adopt new LSP extensions ahead of client support.

Proposal:
Introduce a configurable error reporting level in LSP4IJ, for example:

• Strict (default): current behavior, fail on any protocol mismatch.
• Warn: log the error, show a warning to the user, but continue consuming other responses.
• Silent: ignore unsupported responses, continue with available features.

Benefits:

• Improves resilience of LSP4IJ-based plugins against evolving language servers.
• Allows users to continue working with partially compatible servers.
• Provides flexibility for plugin developers and end users to choose the desired balance between strictness and usability.

Suggested Implementation:

• Add a configuration option (e.g. in plugin settings or via API) to set error reporting level.
• Wrap JSON-RPC response handling with a try/catch that respects the configured level.
• Ensure warnings are logged in IDE event log for transparency.

Example Use Case:
With Haskell Language Server, importLens may fail due to rule mismatch, but other features (completion, diagnostics) remain usable. Under "Warn" mode, the plugin would log the error but continue providing those features.

Start by tracing the JSON-RPC response handling described in the issue and review the existing plugin settings or API entry points. Define how Strict, Warn, and Silent modes should be configured, then verify that unsupported responses no longer stop compatible services and that Warn mode reports the error to users.