Fixes #243 honoring mutable cache ttl-ness in getOrElseUpdate and hit

The way I discovered the "issue" was by using a CachedReadableStore with a MutableTTLCache being the cache implementation of the store. I am basically using it to store metadata about some object that doesn't change frequently, but is needed on a frequent basis. I don't want to call out to my underlying store more than necessary, and working on slightly stale data is acceptable. In this case, CachedReadableStore calls getOrElseUpdate which calls hit() on the underlying cache, not get(). This makes perfect sense for something like an LRUCache, so I didn't want to change the behavior or getOrElseUpdate as that would be more far reaching than necessary, and probably not even correct.

When I made the changes I thought this was just a bug in how ttl-ness was being interpreted. Now I can see situations where a "soft-ttl" is desirable, like storing a user's session based on activity. However, having a "hard-ttl" is also desirable if you don't want the information in the cache longer than the specified ttl, period. In any event,  bypassing the call to get() in the hit() function also bypasses any ttl-ness set on the entry, and I think needs to be addressed regardless, as @Ianoc alluded to.

However, when dealing with a strict ttl, I do not think a call to hit() should call += and effectively reset the clock on the ttl. Perhaps adding a flag to the constructor would be the best way to achieve the desired behavior? Something like
MutableTTLCache(..., strictTTL: Boolean = false). We would obviously default to false which would maintain any backward compatibility.