Issue 52 Resilience Strategy

I've completed all the wiring in to Ehcache and written the ResilienceStrategy interface, and abstract RobustResilienceStrategy superclass, and created a single concrete subclass LoggingRobustResilienceStrategy that is used by default by Ehcache.  What is still left to do here:

* Javadoc for the ResilienceStrategy interface and it's subtypes
* Unit testing for the Ehcache wiring (could be covered under #147)
* Unit testing for the ResilienceStrategy implementations (shouldn't be that complex)
* Configuration wiring to allow users to configure an alternate strategy.

The recovery logic for the concurrent methods is currently very simple.  I think all of it can be justified all though it could be made more advanced.  I would however recommend holding off on this until after the situation with #163 and #159 is sorted out, since that will have a strong influence on how recovery is done.

My understanding here is that the resilienceStrategy is only concerned with the resilience of the cache.  If there is a loader/writer failure that is coincident with a cache failure then we'll tell the resilience strategy about the loader/writer failure because it might be connected to the cache failure.  If the cache loader/writer fails on it's own however then those errors should be thrown, since if there was no cache they would be thrown directly from the SoR.  This is why the Cache interface methods are declared to throw the loader/writer exceptions.  Make sense?