Memcached switches

Ever since moving to the `MemcachedFallback`, we have seen `facia-tool` slow down significantly.

This is reflected in an increase in the graphs for GC time and average CPU load for `facia-tool` at the time of merge.

I am suspicious about the zipping that happens on the data before it is put into `memcache`; it is just using standard java Gzipping which I reckon is slow.

This PR contains:
 - Seperate switches for the `MemcachedAction` and the `MemcachedFallback`. @gklopper This will need a reset of the switch on CODE and PROD since I have changed the name
 - Switch around the use of the `MemcachedFallback` object
 - [Snappy](https://code.google.com/p/snappy/) dependency; specifically [snappy-java](http://code.google.com/p/snappy-java/), a JNI based implementation
 - New `Codec`s for the `Snappy` implementation and a non Gzipped implementation
 - Switch around the `Codec` used for zipping

I have also switched over the zipping to the `Snappy` implementation.

I have not diluted the cache key; these all should get replaced on every request.

@robertberry 
I would actually give this an initial expiry date. That forces you to look at it again in say 2 weeks. If all is well after that change it to never.