storeAsBinary makes it near-impossible to use JdbcStringBasedCacheStore with non-standard key types

When storeAsBinary is enabled, there is a special MarshalledValueInterceptor inserted into the interceptor chain. This interceptor wraps the keys (and values) in MarshalledValue; this wrapper is then used in all interceptors as the actual key (or value). One of the interceptors that receives this wrapper is the CacheStoreInterceptor which indiscriminately passes it on to the configured CacheStore. The cache store is then supposed to store this wrapper for later retrieval.

This works fine for cache stores that marshal the key (or value) as-is, without concern of its actual type. But there is this one very useful cache store, the JdbcStringBasedCacheStore, which is very concerned with the actual type of the key as it wants to be able to convert it to String and from String back again to the key type. When storeAsBinary is disabled, it works as designed; but when storeAsBinary is enabled, the actual key that the cache store receives may be the MarshalledValue wrapper which causes lot of confusion - the configured Key2StringMapper is not prepared to handle MarshalledValues; and even if it is, it cannot tell reliably whether it is supposed to wrap the key reconstructed from String (if it implements TwoWayKey2StringMapper).

NOTE: this wrapping is, though, disabled if the key type is a "known" type - most notably primitives and String. That's why it's not a problem for majority of use cases where the key type is not non-standard.

I strongly believe that [TwoWay]Key2StringMapper should never be concerned with MarshalledValues, and that JdbcStringBasedCacheStore should take upon itself the task of wrapping and unwrapping the keys as required.