New files implementing an asynchronous cache.

A class implementing an asynchronous cache.  That is, if a cache value was found in the cache, but it is expired, this stale value will be returned and an asynchronous task will be started to regenerate the cache value.  This eliminates the cache MISS time penalty for most cases.

Also included is a test script for this class.  Example usage:
```shell
  php ./asyncCache.php --get animal --ttl 20 --regen-ttl 10 --generate-args cat,5
```
This will fetch the key 'animal' setting a TTL of 20 seconds if it has to be regenerated and cached.  It will serve stale data for 10 seconds (--regen-ttl) if the cache is found but stale and the asynchronous job has not completed.  It will call the default test function 'AsyncCacheTestGenerator::getValue' with arguments 'cat' and 5.  Here 'cat' is the value to store and 5 is the number of seconds the job should sleep to simulate an expensive request.

If this is run several times the output will show in what state the cache is in.  Changing 'cat' to 'dog' will help show when stale values are being served while the 5 second regeneration job runs.

Additional parameters are available to test the other functionality of AsyncCache and are described via:
```shell
  php ./asyncCache.php --help
```
Not exactly, the negative TTL is always set regardless of the outcome.  Let me outline a sample usage:

1) We cache a value that is dependent on a service response with a TTL of 12h and a negative TTL of 5m
2) During normal caching the values will only be recomputed every 12 hours
3) The service begins to fail and it takes 1 minute to timeout.
4) When the 1m timeout is reached, the value generating code throws the NegativeResponseException exception
5) This is caught by AsyncCache which sets the TTL to 5m rather than 12h
6) The generating code returns some null/default value (empty string, empty array etc)
7) When the service problem clears up, it only takes 5m to get a valid value rather than 12 hours if there was only one TTL defined.

In general, you don't want to cache negative responses; you just want to keep trying until you can get something valid.  But in this case its costly to keep calling the failing service, taking 60s every request.  This can lead to requests stacking up.  You can solve this by caching the negative response, however if you cache it with the same TTL as a good response, you can have this null value in the cache long past when the problem cleared up.