Implement max_size and eviction policies about cachex

[whitfin]

More thoughts on LRU:

• We can provide a touch function which is basically refresh without updating the TTL (so it just updates the write time).
• An LRU policy can simply invoke the LRW policy, but add in a hook which touches keys when they're read.
• If you don't want all keys to be read, maybe we add a touch: false option to all read operations?
• Alternatively, you can just use an LRW policy and touch keys when you wish.

This would mean that we only have one heavy lifting policy (LRW), but support both the LRW and LRU use cases. I think this is elegant, and should suffice for now - things like LFU would be extremely difficult to implement without introducing higher memory usage.

[whitfin]

Currently I have an implementation of an LRW (least-recently written) hook which works and caps based on a given reclaiming boundary. This is implemented entirely without need for separate storage and is actually quite cheap, and seems to be pretty fast (as much as you can expect, anyway).

Not entirely sure about how to create an LRU which doesn't need some sort of key tracking, which would naturally make it way more expensive (because there would be a write on every read). It may just be that we go with just LRW for 2.x and direct people to touch their keys as needed.

[whitfin]

LRW is merged in. LRU is going to take a little time because there are a few other issues to cleanup first before I take a shot at that (because I'd just have to rewrite it).

@emerleite feel free to play around with Master to try out the limits.

[emerleite]

@zackehh thanks. I'll start using this next week ;)