Add caching layer for skins

Added basic in-memory caching of avatars, which is quite fast and would help out a bit for serving the most viewed avatars. Set a rough limit of 64 MB of in-memory cached data.

```
Looking at response times, running Siege on a Macbook Air.

============================================================
Response time before caching was added:

For all requests: 0.082 secs

============================================================
Response time after caching was added:

Getting the same avatar 100 times: 0.014 secs # best case, >4x increase in speed!
Getting a unique avatar 100 times: 0.083 secs # worse case -, not much different from before caching
Getting the same set of 10 avatars 1000 times: 0.013 secs

============================================================
Letting it run and taking a nap, peak memory usage in caching. Expected
it to peak around 64 MB. Looks like there's actually a memory issue elsewhere.
Increased ad infinitum, even on the current master branch without my caching addition.

============================================================
Am now banned from Mojang API: definitely.
```

The timings in the request log makes me much more happy than before :)

```
[15:25:36.474659] INFO Serving skin for connor4312 (184+0+6=191ms) md5: d05a3eda6f8b1d3b8dfae6315c3aae65
[15:25:37.165298] INFO Serving skin for connor4312 (0+0+5=5ms) md5: d05a3eda6f8b1d3b8dfae6315c3aae65
[15:25:37.442426] INFO Serving skin for connor4312 (0+0+4=4ms) md5: d05a3eda6f8b1d3b8dfae6315c3aae65
[15:25:37.710710] INFO Serving skin for connor4312 (0+0+4=4ms) md5: d05a3eda6f8b1d3b8dfae6315c3aae65
[15:25:37.979408] INFO Serving skin for connor4312 (0+0+4=4ms) md5: d05a3eda6f8b1d3b8dfae6315c3aae65
```
That's fine. It keeps skins people view the most at the top of the cache, so it keeps itself up to date in a rather natural way. This wasn't designed so much for the minotar.net service, as that's behind CloudFlare, but rather for people who run Minotar instances themselves. In those cases, the constantly updated cache would work well - perhaps their entire userbase would fit into a 64 MB cache!