[performance] Avoid reading SourceFile twice

[jukzi]

During compile parsing happens in two stages:

1. diet parse (any blocks like method bodies are skipped)
2. parse bodies Both phases did read the source .java file from file system. With this change the file contents is kept in CompilationResult.contentRef until no longer needed. It is cached in
   a SoftReference to avoid OutOfMemoryError.

#2691

[HannesWell]

2. It is cached in
a SoftReference to avoid OutOfMemoryError.

Since I see you using SoftReference in more and more places I want to add a word of warning:
While the idea is tempting, using a lot of SoftReferences can cause serious performance problems. Depending on their count, the memory they retain, the JVM implementation respectively the GC in use and it's settings, it might happen that the GC is in constant 'panic' and trying to free memory but only a little and blocking the entire application with that.

See for example from this article Weak, Soft, and Phantom References in Java:

You need to keep in mind that filling almost all your memory can slow down your program so much that a cache hardly matters.
It’s easy to verify this just by running the program and uncommenting the line that creates the SoftReference.

Or for example this comment were I learned this myself: google/guava#5311 (comment)

So if SoftReferences are used (a lot), because all this is fuzzy, actually sophisticated benchmarks with different loads, GCs and CG-settings should be done to ensure there is an overall net benefit in using them.
Of course it would be ideal if they are simply avoided by a different logic or program flow, but I have no clue if this is possible.

[jukzi]

Depending on their count, the memory they retain

therefore do measurements, measurements and measurements. Like in all good science.

@stephan-herrmann i think i adapted the code as you demanded and i like the CompilationResult way. Do you want to review? Please just leave a message if you need more time.

Merge conflicts solved - CompilationResult had javadoc above the imports, which could not be automatically solved.