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.

I personally wouldn't use convenience as the reason to have both in place since implementing methods overloaded in the interface but redundant otherwise makes me cringe a bit... as for performance, I doubt we care that much about it when we're in the path of catching a `CacheAccessException` anyway. 

As for the last one, if the whole cache appears busted, then perhaps define it as `recovered(Cache, CacheAccessException)`?