Improve uncaught exception handling ("Internal Error" popups)

Currently uncaught exceptions on the server side result in a generic "Internal Error" popup in VSCode:


The reason for this is that LSP4J places the stacktrace in the `data` field which is apparently ignored on the client side:

```json
Content-Length: 2789

{
"jsonrpc": "2.0",
"id": 0,
"error": {
"code": -32603,
"message": "Internal error.",
"data": "java.lang.RuntimeException: java.lang.reflect.InvocationTargetException\r\n\tat org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:67)\r\n\tat org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.request(GenericEndpoint.java:120)\r\n\tat org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleRequest(RemoteEndpoint.java:261)\r\n\tat org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:190)\r\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:192)\r\n\tat org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)\r\n\tat org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:99)\r\n\tat java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)\r\n\tat java.util.concurrent.FutureTask.run(FutureTask.java:266)\r\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\r\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\r\n\tat java.lang.Thread.run(Thread.java:748)\r\nCaused by: java.lang.reflect.InvocationTargetException\r\n\tat sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\r\n\tat sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)\r\n\tat sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)\r\n\tat java.lang.reflect.Method.invoke(Method.java:498)\r\n\tat org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:65)\r\n\t... 11 more\r\nCaused by: java.lang.IllegalArgumentException\r\n\tat sun.nio.fs.WindowsFileSystem.getPathMatcher(WindowsFileSystem.java:288)\r\n\tat org.javacs.kt.classpath.FindClassPathKt.ignoredPathPatterns(FindClassPath.kt:75)\r\n\tat org.javacs.kt.classpath.FindClassPathKt.workspaceResolvers(FindClassPath.kt:62)\r\n\tat org.javacs.kt.classpath.FindClassPathKt.access$workspaceResolvers(FindClassPath.kt:1)\r\n\tat org.javacs.kt.classpath.FindClassPathKt$findClassPath$resolver$1.invoke(FindClassPath.kt:14)\r\n\tat org.javacs.kt.classpath.FindClassPathKt$findClassPath$resolver$1.invoke(FindClassPath.kt)\r\n\tat kotlin.sequences.FlatteningSequence$iterator$1.ensureItemIterator(Sequences.kt:279)\r\n\tat kotlin.sequences.FlatteningSequence$iterator$1.hasNext(Sequences.kt:267)\r\n\tat org.javacs.kt.classpath.FindClassPathKt.findClassPath(FindClassPath.kt:116)\r\n\tat org.javacs.kt.CompilerClassPath.refresh(CompilerClassPath.kt:13)\r\n\tat org.javacs.kt.CompilerClassPath.addWorkspaceRoot(CompilerClassPath.kt:33)\r\n\tat org.javacs.kt.KotlinLanguageServer.initialize(KotlinLanguageServer.kt:68)\r\n\t... 16 more\r\n"
}
}
```

Unfortunately, VSCode's output log also disappears once the language server terminates. The question is thus whether there is a better way to display uncaught exceptions, ideally featuring the stacktrace.

Start by reproducing an uncaught server exception and inspect the LSP4J error response, especially its data field, alongside the VSCode output behavior after the language server terminates. Determine where the extension receives and displays server errors; done means a clear exception message and stack trace remain available to the user.

Written by the indexing model from the issue text.