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

[timeck]

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 Caches
• 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

[terracotta-org]

Test PASSed.

[ljacomet]

Looks ok to me

[alexsnaps]

Think it needs rebasing, but could then be merged in. (Ehcaching disappeared for instance... should create some 'trouble')