limit concurrent png resizes per box

We serve full sized PNGs at the moment.  We want to serve resized PNGs but although they are very cacheable once resized, we don't have the cpu time to resize them at the rate needed to fill the cache.

So this PR is to limit the number of concurrent resizes to 2*cores, after that it will 307 redirect them to the original static image.  This means we will be resizing the images as quickly as we can according to demand, but if we can't cope we can offload the resize onto the browser.

Latency will always be good, so we will never autoscale with the current rules, so we may need to modify the health check so we scale up/down if there are too many/too few 307s in a given time period.

We can also potentially save ourself a lot time resizing images that haven't changed since last time by adding an ETag/last-modied from the original image and returning 304 if it's not changed.  This would remove the trade-off of long cache times.

@gklopper @robertberry any thoughts?
Might be worth getting rid of the `Action.async{...}` and simply replacing with `Action{...}` - (maybe not in this PR though).

That way you could get rid of all the Synthetic `Future.succesfull` calls.