Make the JSON server's computation limit configurable

[vogella]

The VSCode JSON language server computes document symbols and folding ranges for the whole document unless the client configures a limit, and Wild Web Developer never sent any configuration at all. On a 100,000 line JSON file that means 20,001 symbols and folding ranges per request, and with the Outline view open the UI thread was busy for two to three seconds per keystroke, which makes such files impractical to edit.

This adds a JSON preference page with the maximum number of computed items, defaulting to 5000 just like VSCode's json.maxItemsComputed and the existing YAML preference, and 0 to switch the limit off. In the same measurement the editor now spends about 23 ms of UI thread time per keystroke with the Outline view open, which is what it already cost with the Outline closed. The limit is sent through the usual preference machinery, so changing it takes effect without restarting the language server.

Two entries that only restate defaults have to be sent along, because this server re-reads all of its settings from every notification: without json.validate.enable it silently stops validating, and without http.proxyStrictSSL it stops verifying certificates when downloading remote schemas.

Note that outlines of files with more than 5000 symbols are now truncated, exactly as they are in VSCode and as YAML files already are here.

[vogella]

The three CodeQL alerts on TestJSONResultLimitPreference were false positives: jsonDefinition was read inside the lambda, the list was filled through the servers::addAll method reference, and jsonServer was passed to countSymbols twice. The CodeQL workflow analyses Java with build-mode: none, so it has no classpath and cannot resolve the LSP4E and LSP4J types, which makes every expression touching them opaque to it.

I still reworked the test rather than dismissing the alerts, since the code was more convoluted than it needed to be. Looking up the language server is now folded into a helper that returns it directly, so the three locals and the mutable list are gone and the test body is just two assertions around the preference change. It also filters nulls from collectAll explicitly instead of relying on the first element being the JSON server. The test still passes.