FIX: Deliberately clear partial cache blocks on flush (fixes #1383)

The new `Flushable` stuff reintroduced a bug where `i18n::flush()` would clear partial cache blocks from templates, instead of just clearing translations. Obviously, this bug is desirable and has actually been in-place since d3b63dae0c7913689124a760ecbcbf136bd64d2a (excluding 3.1.6, where [I “fixed” it](https://github.com/silverstripe/silverstripe-framework/commit/d012b79cf0fbedcb8ad483d63d0be7c4c051c8a5) - sorry about that).

So now, `i18n` only clears its own tag (if you’re curious, the tag name `Zend_Translate` comes from [here](https://github.com/silverstripe/silverstripe-framework/blob/3.1.6/thirdparty/Zend/Translate/Adapter.php#L965)) and `SSViewer` clears its own cache too.

Ideally, `SSViewer::getPartialCacheStore()` would use some DI or Injector magic, so we wouldn’t have to hardcode which cache we clear, but that’d presumably be an API change. We’d need to ensure the partial cache store was registered before `SSViewer::flush()` was called.

I appreciate the unit test is a bit... odd... but I wanted to be explicit in ensuring that visiting a url with `flush=1` definitely clears the cache. Now that I look back at it, I’m not sure that’s a good idea after all. Will await feedback on that.
Sure. Would a PR like that be better against master (I’m not sure if loads of line changes makes merging upstream a pain in the a** for core devs)?