For review only -- Issue #87

Some notes about what this is about:
- Allow discrete classloaders for a `CacheManager` and for individual `Cache`s
- If a classloader is specified for a `CacheManager`, caches created in that manager will inherit the classloader if the `CacheConfiguration` does not specify another explicitly
- The default classloading behavior same as ehcache 2.x, prefer TCCL then use loader that loaded ehcache 
- changed `java.util.ServiceLoader` calls to explicitly use the classloader that loads ehcache
- Plumbed `ClassLoader` down to `Store.Confuguration`. My believe is that Store's will need to be told the classloader
- There are multiple `parseConfiguration()` signatures now in `org.ehcache.config.xml.XmlConfiguration` that let people specify the classloaders when interacting with xml configs
- It's not yet clear to me where user specified classes (for maybe something like a `CacheWriterFactory`) will be instantiated, but those calls would need to get a classloader provided to them
- No tests yet, not intending for this to pull into master. just for review

 

I don't think so. The default classloader is an implementation that uses TCCL. For service definitions we want to load with `java.util.ServiceLoader` only the ehcache library loader should be used. In fact the previous calls were using the 1 argument form of `ServiceLoader.load()` which prefers TCCL and will cause no end of problems for people in runtimes like OSGi