DONT MERGE YET... Review for now

  - Adapted `Store` SPI to current `Cache` API
  - `Ehcache` delegates to `Store` and handles `CacheAccessExceptions`
Well, my take is this:
 - `Store.ValueHolder` represents the minimal contract a `Store` as to honor, to be used by a `Cache`
 - `Store.ValueHolder` is only there to support a returned value that encompasses all that. 
 - Also lets you play trick around avoiding the need to deserialize the value entirely when you don't need to (e.g. accessing an expired entry, w/o having to fire a notification holding the old value)
 - *Not* as a mean for the `Cache` to store any random data

Given these, having a put that requires you to provide all information about the entry being mutated, seems good enough. Introduces large method signatures possibly though, but avoid an allocation, that won't really be required anyways (i.e. for anything other than an on-heap `Store` implementation, though even there you could avoid it).  

Any additional data that the `ValueHolder` may be tempted to store (like the accessed bit of a `ClockEvictor`) become `Store` internal concerns that should leak out anyways... 

Or am I missing something (in that reasoning, or is it even incomplete)?