anchor.diff:  will lookup a `Store.Provider` which is one of the bundled `Service` types of Ehcache, asking it to create a `Store` based
   on the `CacheConfiguration` used to configure the given `Cache`. That indirection, makes both the `Cache` as well as the
   `CacheManager` ignorant of what topology this `Cache` is to use. Ehcache comes with a `DefaultStoreProvider` that will
  -be loaded by the `ServiceProvider`, should one be explicitly provided. That in turn will resolve the required `Store`
  +be loaded by the `ServiceProvider`, should none be explicitly provided. That in turn will resolve the required `Store`
   instance to be provided to the `Cache` being created.
   
   image::https://raw.githubusercontent.com/ehcache/ehcache3/master/docs/images/design/basics/cacheStore.png[Cache's Store]
   
   The `Cache` also tries to never _fails_ on operations invoked, e.g. a get shouldn't result in throwing an exception if the
   `Store` that backs it up uses serialization and fails to retrieve the mapping. Instead, Ehcache tries to be resilient and
  -should try to clear that mapping from its `Store` and return `null` instead to the user. It is the responsibility of the
  +will, by default, try to clear that mapping from its `Store` and return `null` instead to the user. It is the responsibility of the
   `Cache` to handle the exceptions a `Store` may throw (the `Store` interface explicitly declares it throws
   `CacheAccessException`, which is a checked exception). The `Cache` will delegate failures to the `ResilienceStrategy`,
   which in turn is responsible for handling the failure.
  
positive.code: === The new `UserManagedCache`
  
  The `UserManagedCache` are, as the name implies, managed by the user instead of being managed by a `CacheManager`. While
  these instances a meant to be lightweight, short-lived ones, nothing prohibits a user from building a distributed
  `UserManagedCache` if so desired.
  
  As the user manages that instance himself, he needs to provide all `Service` instances required by the `UserManagedCache`.
  
negative.code: 
  === Clustered topology
  
  In a Terracotta clustered scenario, all clustered `Cache` instances are considered persistent (i.e. will survive the
  _client_ JVM restart). So the idea is to provide all clustered configuration passing such a
  `CacheManagerConfiguration<PersistentCacheManager>` instance, with all the Terracotta client configuration stuff, to the
  `CacheManagerBuilder` at construction time.
  