anchor.diff:  Serializers are scoped at the cache level: a cache can have a serializer for its keys and another one for its values.
   All stores of a cache will be using and sharing the same key and value serializer pair.
   
  -=== Copiers
  -
  -As the on-heap store is capable of storing plain java objects as such,
  -it is not necessary to use a costly serialization and deserialization mechanism to copy keys and values when a
  -on-heap store is configured to store by value. For instance, some form of "copy constructor" mechanism is a lot
  -more performant but requires custom code to be able to copy objects.
  -
  -Copiers are specific to the on-heap store: no other store makes use of copiers.
  -
  -By default, the on-heap mappings are stored by reference. The way to store them by value is to configure some copier(s)
  -on it, either key, value or both.
  -
  -=== How is a serializer configured?
  +==== How is a serializer configured?
   
   There are two places where serializers can be configured:
   
  
positive.code: 
  Registering a serializer that lacks such constructor at the cache manager level will prevent it from being chosen for persistent caches.
  
  Since copiers only relate to the on-heap store and the latter cannot be made persistent, the above doesn't apply to them.
  
  === Lifecycle: instances vs class names
  
  When a serializer instance is configured using either of
  `CacheConfigurationBuilder.withKeySerializer(Serializer keySerializer)` or `CacheConfigurationBuilder.withValueSerializer(Serializer valueSerializer)`,
  it is up to you to manage the lifecycle of the Serializer instance, ie: dispose of any resource the serializer might hold upon and/or persisting and reloading
  the serializer's state.
  
  Since copiers only relate to the on-heap store and the latter cannot be made persistent, the above doesn't apply to them.
  
  When a serializer or copier class is configured (either at the cache or cache manager level), since Ehcache is responsible for creating the
  instance, it also is responsible for disposing of it. If a serializer or copier class name is configured and that class implements `java.io.Closeable` then
  `close()` will be called when the cache gets disposed of.
  
  === ClassLoaders
  
  todo.
  
  == Writing your own
  
  === Writing a serializer
  
  Serializers must act as such, so if you're planning to write your own implementation you have to keep in mind that
  the class of the serialized object MUST be retained after deserialization, ie:
  
negative.code: 
  All bundled serializer implementations support both persistent and transient caches.
  
  ==== Persistent vs transient caches
  
  When configured on a persistent cache, serializers may need to persist and restore their state across restarts, so you have to implement a
  constructor that accepts `ClassLoader classLoader, FileBasedPersistenceContext persistenceContext` otherwise persistent caches won't be able to
  