Disable warmup of orchard.java caches

[alexander-yakushev]

After the recent improvements to orchard.java parsing machinery (which also included performance improvements), I find it no longer necessary to perform project-wide cache warmup for Java classes at cider-nrepl startup. The reasoning is below:

• orchard.java/class-info has sufficient performance now, even when not yet cached. For example, (orchard.java/class-info 'clojure.lang.Compiler) takes ~150ms on my machine. This delay is slightly noticeable during the first cider-doc, but this is one of the biggest Java classes (10k LOC). One of the biggest JDK classes, java.lang.Character, takes ~80 ms to be parsed. Also, when jump-to-definition is invoked, the waiting time is much more noticeable there because it is dominated by locating the source file in the archive, extracting, and presenting it to the user (Emacs side). The Clojure-side cache doesn't improve it much.
• Because orchard.java/class-info contains invasive side-effects like loading all project-wide classes in the background, it led to issues in the past like orchard.java/class-info class initialization breaks JavaFX orchard#250, parser_utils/parse_java taking a long time. orchard#240, and possibly orchard as dependency will cause problems with swing UI applications orchard#162 (not sure about this one, have to investigate further).
• Running non-trivial code in the background overall rubs me the wrong way a bit.

So, I decided to remove the warmup for parsing Java classes. I was planning to remove the warmup code altogether, but then noticed that it claimed it warms up Compliment completions too which it doesn't. I decided that warming up one specific instance of Compliment completions (.prefix Java member completion) can be beneficial (it has a perceivable delay on first invocation) and is maximally non-invasive as much as I understand (it doesn't do any classloading and relies solely on classpath scanning). However, I also don't mind not including it and removing the warmup code completely, I'm not overly attached to the Compliment warmup.

If we are to keep the warmup, I also want to replace future with an explicit Thread.start to avoid initializing Clojure's agent pool for the user.

• You've updated the CHANGELOG

[bbatsov]

I like your current proposal and I agree that if the speed now is reasonable it's not worth it to cause problems for end users with the invasive caching.