Investigate a custom URI scheme for decompiled *.class resources

[fwcd]

Currently, external class files are (when the user requests a "Go-To-Definition") decompiled into a temporary file on disk and transferred to the client by referencing the corresponding file URI. Temporary on-disk resources depend on a cleanup hook, which may or may not run, depending on whether the language server process is forcefully terminated.

Similar to how the Java language server does this, it might be cleaner to have a custom URI scheme for resources inside JAR files. For example, replacing:

file:///C:/Users/.../AppData/Local/Temp/fernflowerOut8413035485521351592/Runnable7065471160245853737.java

by something like:

kls://contents/rt.jar/java.lang/Runnable

VSCode supports this through the use of Virtual Documents, Atom provides an API for readonly documents too.

Challenges with this approach include, however:

• Ensuring that the client supports these URIs (e.g. by registering a capability) and otherwise falling back to temporary files
• Having to maintain a non-standard LSP request under which the language server can dynamically serve the text content of these temporary resources (JDT.LS calls this java/classFileContents)

For discussions around the JDT's approach, see:

• Navigation to *.class file (jdt:// scheme) is missing atom/ide-java#42
• Only return jdt:// urls if clients support it eclipse-jdtls/eclipse.jdt.ls#649
• Uris like jdt://... not supported autozimu/LanguageClient-neovim#392