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.

The last one definitely can't be since it represents "the whole cache was inconsistent but we recovered it" - it's semantically equivalent to the Iterable version being passed the full key set - not an empty set.  The other split could be collapsed, but for performance (and convenience) reasons I'd like to keep the single key version here.  Does that make sense?  An implementor is of course free to collapse them.