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.

Should the an indication of whether or not the loader/writer has been mutated/called be added to the store-only calls?  I believe the sequence of operation came up in discussion but I don't recall whether or not CacheAccessException thrown before a call to the loader/writer versus CacheAccessException after a call to the loader/writer ever came up.