Add support for jdtls' class-file-contents feature

[HungryJoe]

I've been using Java a lot lately, and my projects depend heavily on third-party libraries. In the Java ecosystem, libraries are typically distributed (and installed by maven, a common Java dependency-management tool) as archives (so-called JARs) full of compiled source files, which we call "class files." To support callers' viewing the definitions of these libraries' symbols, there are a wide variety of so-called "de-compilers," which take a class file and render source code that could be compiled to generate it. The legality of using these tools on proprietary libraries is questionable in some places, but I think that the legal risk here lies fully with the end user. But anyways, when I type gd on a symbol defined in a third-party library, I'm really asking Helix to show me that symbol in a decompiled version of the class file it originates from.

JDT-LS, the best Java language server out there, is able to serve decompiled class files, but it extends the language-server protocol to do so. This extension chooses to serve decompiled class files via a custom URI scheme, jdt:https://, which is informally documented here. Would some kind being be willing to add support for this extension to Helix? It'd bring the project much closer to parity with an Eclipse or IntelliJ (the two leading enterprise-grade Java IDEs) in terms of Java support.

P.S. I provide a lot of context on Java in this request in case the maintainers of Helix aren't real frequent Java users. If y'all were, I'm guessing that this feature would already be supported 😂

[kirawi]

We don't intend to support any LSP extensions in core and defer them to the plugin system.