anchor.diff:  
   === Clustered topology
   
  -In a Terracotta clustered scenario, all clustered `Cache` instances are concidered persistent (i.e. will survive the
  +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.
  
positive.code:  gets registered with it. These `Service` can then be looked up, e.g. by `Cache` or other `Service` instances, using the
   `ServiceProvider` interface;
   - Finally, the `CacheManager` acts as a repository of alias'ed `Cache` instances. Unlike in the previous versions, `Cache`
   instances aren't named, but are registered with the `CacheManager` under an _alias_. The `Cache` is never aware of it.
  
  This diagram tries to summarize the different roles:
  
  
negative.code:  .. If it doesn't, it looks up all `ServiceFactory` it has for one that creates instances of that `Service` type.
   ... If one is found in that `ServiceFactory` repository, it uses that to create the instance
   ... If none is found, it uses the JDK's `java.util.ServiceLoader` service to load `ServiceFactory` and recheck
   .. If nothing could be found, an Exception is thrown
  
  === Builder design guidelines
  
  