Issue #87, ClassLoader fun. For real this time, tests and all

Some notes about what this is about:
- Implemented `Cache.getRuntimeConfiguration` by copying config used to create cache. Mutators still throw exceptions
- 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