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.

Isn't the resilience strategy used to establish/ensure conditions for continued operation in the event of a fault?  To me, that would include a failure in obtaining a value for a key not in the "local" cache.  The caller could handle the CacheLoaderException but that provides no where near the detail needed to programmatically determine what caused the failure.