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.

Hmmm ... I still have misgivings about leaving the default behavior a simple log.  The 'inconsistent' methods are called when a RobustResilienceStrategy 'cleanup' method has failed to clean up ... at this point the cache can't be trusted and, to me, simply logging the clean up failure isn't enough -- the application needs a strong signal that the cache should no longer be used.  Operation of the cleanup methods depends on the Store implementation provided to Ehcache -- my understanding is the Store implementation is something the user can supply so any assumptions we may have about the sanity of Store implementation are out of the window.

Having said that, I can't say that I know what's coming down the pike for supplying Store and ResilienceStrategy implementations ...