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 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.
More prosaic, two reasons:

1. I can never remember if it's `exist?` or `exists?` so I typed `File.exist?` into irb and lo (in fact, `File` supports both, a fact I have only this second been forced to acknowledge).
1. It reads better in the spec - `expect(Postgres::MaterializedView).to exist('name')` as opposed to the frankly sick-making `expect(Postgres::MaterializedView).to exists('name')`

In light of the above, I propose doing as stdlib does and aliasing one to another to support both.