[WIP/RFC] Refactored CacheInvalidator into descreet units

- Renamed and repurposed CacheInvalidator => CacheManager
- CacheManager now delegates to handlers
- Added handlers for each use case

Usage:

````php
$cache = new Varnish();
$pathHandler = new PathHandler($cache);
$tagsHandler = new TagsHandler($cache);

$cacheManager = new CacheManager(array(
    'path' => $pathHandler,
    'tags' => $pathHandler,
));

// invalidate by path
$cacheManager->invalidate('path', '/path/to');

// invalidate by path with headers
$cacheManager->invalidate('path', '/path/to', array(
    'headers' => array(
        'X-Foo' => 'bar'
    )
);

// invalidate tags
$cacheManager->invalidate('tags', array('foo', 'bar'));

// refresh a path
$cacheManager->refresh('path', '/path/to');

// flush -- will flush all the cache implementations used
// by the handlers (once)
$cacheManager->flush();
````

Each handler has its own cache proxy instance. This would allow different cache
implementations to be used simultaneously if required.

NOTE: Tests are currently missing.

Yeah, this was an awkward decision.

Basically if we inject the cache-handler as a constructor to each handler then we open the possibility that each handler could have its own cache implementation - which is a nice flexibility.

However, I think we want to have a `flush` method on the `CacheManager`. Without this method we could call `flush()`  multiple times on the same cache implementation.

I also considered having a proxy method, `getCache` which replaces `flush()` - but then that kind of breaks the encapsulation.

I guess this "method" could be improved by returning the object ID / hash rather than the class.

Any other ideas?