Support source attachments for dependencies

### Motivation

Currently the language server stores symbols (i.e. variables, classes, ...) in two locations:

* The [source path](https://github.com/fwcd/kotlin-language-server/blob/master/server/src/main/kotlin/org/javacs/kt/SourcePath.kt), containing the parsed `.kt` source files from the user's workspace
* The [class path](https://github.com/fwcd/kotlin-language-server/blob/master/server/src/main/kotlin/org/javacs/kt/CompilerClassPath.kt), containing a list of `.jar` archives that the user's project depends on (e.g. the standard library, dependencies, ...)

If a user decides to lookup a symbol (e.g. by Ctrl-Clicking in his editor), the language server will attempt to locate the source code of the definition. For files on the source path this is straightforward: It just opens the source file in the workspace. For files on the class path (e.g. libraries used by the project) this is a bit trickier, however, since the `.jar` archives only contain compiled JVM bytecode. To work around this, the language server currently uses a decompiler to provide source code that at least is functionally equivalent to the original definition.

This has a few disadvantages, however:
* Comments, variable names, documentation, etc. gets lost
* The structure may not exactly reflect the original code

Since many libraries provide a source jar as well, the question would be, whether we could try to locate the jar and integrate into the current class path.

### Tasks

* Locate the source attachment jar alongside the class path jar
* Note that this requires Maven/Gradle-specific logic and should ideally be integrated into the ClassPathResolvers
* Map class path jars to these source attachment jars

### Ideas

* Possible introduce a new `data class` describing a class path entry with
* a compiled jar
* a source attachment
* possible a doc attachment (in a future issue)

### Useful starting points
* The [Go-To-Definition implementation](https://github.com/fwcd/kotlin-language-server/blob/master/server/src/main/kotlin/org/javacs/kt/definition/GoToDefinition.kt)
* The [class path store](https://github.com/fwcd/kotlin-language-server/blob/master/server/src/main/kotlin/org/javacs/kt/CompilerClassPath.kt)
* The [different ClassPathResolver implementations](https://github.com/fwcd/kotlin-language-server/tree/master/shared/src/main/kotlin/org/javacs/kt/classpath)

Start with GoToDefinition.kt and CompilerClassPath.kt to trace how dependency definitions currently fall back to decompiled sources. Then inspect the ClassPathResolver implementations under shared/src/main/kotlin/org/javacs/kt/classpath, focusing on how Maven and Gradle dependencies are located. Done means source attachment jars can be found and mapped to class path jars for dependency navigation.

Written by the indexing model from the issue text.