Precompute large site hits

See also https://www.pivotaltracker.com/story/show/79766966

*This PR un-breaks (prevents a 504 on) Analytics / All hits / All time for larger sites like [`hmrc`](https://transition.production.alphagov.co.uk/sites/hmrc/hits?period=all-time) and [`ofsted`](https://transition.production.alphagov.co.uk/sites/hmrc/hits?period=all-time). Note that on production as it stands, these do not always time out - Preview should fall over reliably!  Partly, this PR is to enable further import of all or part of the large outstanding [HMRC hits](https://github.com/alphagov/pre-transition-stats/commits/all_hmrc_hits) corpus.*

For sites we mark as `precompute_all_hits_view = true`, the rake task `import:hits:refresh_materialized` will (re-)create a Postgres `MATERIALIZED VIEW` with a name like `#{site_abbr}_all_hits`, e.g. `hmrc_all_hits`. When All Hits/All time is selected from Analytics, transition will use this view instead of running an expensive query to compute the counts live, which may often time out due to a lack of selectivity in the query (this issue doesn't apply to, for example, All Hits/Last 30 Days, as existing indexes can be used effectively there).

As a rough guide, if a query for all hits, all-time takes around 15s (timing out in nginx and resulting in a 504), use of this view will bring it back down to around 200ms at the cost of paying (less than) that 15s up-front when the view is created by the rake task.

The rake task will need to be scheduled separately - or we can consider adding the same lib call to `import:hits`.

Note: there is no UI facility for marking a site in this way. The site will need to be updated manually through a `rails console` or `psql`. At time of writing, we have two sites that have this problem: `hmrc` and `ofsted`, so it scarcely seems worth adding a UI overhead.
> If we say `replace!` instead, do we lose the actual intent – the why – in favour of the how?

Almost, but not quite: I think the intent is subtly different, because of the fact that we’re saying “make sure the view is refreshed _and_ up to date with how it’s now defined”, rather than just “make sure the view is refreshed”. There may be a case for a `refresh!` method as well in the future.