Renamed to avoid confusion between jarFile vs jarURL
Implemented caching&prefetching

... to the point that at least all the tests pass, so it hopefully does
no harm. I have not yet verified that it does good, nor have I verified
that this works with something real like Jenkins.

The basic idea of this change is:

 - introduce an abstraction ResourceImageRef to indirect the process
   of resolving the actual data, so that IClassLoader calls don't
   blindly send byte[].
 - There's an ResourceImageRef implementation for a file inside a jar
   file (ResourceImageInJar), which fetches a whole jar file and then
   locate a resource inside it.
 - A new subsystem (JarCache) for caching jar files sent by the other
   side, and its implementations, based on jar checksums.
 - A new subsystem (JarLoader) for computing & serving jar files
   based on their checksums.
Bug fix.

Which.jarFile() can return a class directory