Tidy hits_helper_spec

* Remove duplication around TimePeriod stubbing
* Be explicit about a context that wasn't requiring setup
Make hits period strip use all hits as appropriate

* No longer reverts to summary when a time period is chosen
  on all hits
* further tidy spec to concentrate on conveying intent, not implementation
Merge pull request #473 from alphagov/fix-all-hits-summary-bug

Fix all hits summary bug
Remove "All time" link from Universal Analytics

* Was expensive
* This is just a removal of the link; appending period=all-time to a
  Universal Analytics URL will still, at present allow you to *try* to reach it.
Move knowledge of slugs away from views

* Add options to `View::Hits::TimePeriod.all` to allow exclusion of all-time period
* Also tidy up some related specs that were incorrectly nested under `describe '.all'`
Merge pull request #474 from alphagov/remove-universal-all-time-link

Remove "All time" link from Universal Analytics
Update mySQL-centric comment

* There's still a use for truncate_everything, it just has nothing to do
  with myISAM
* It's now for tests that use transactions and avoiding
  PG::InFailedSqlTransaction
Add precompute_all_hits_views to sites

* Allows us to indicate which sites are considered 'large'
* We'll precompute their All Hits view for those sites
Postgres helpers for materialized views

* Let us do Postgres-y things around views in a Ruby-ish way
* We can create them, check existence, get bodies for or refresh
  them
Materialized views rake task

* For any site where precompute_all_hits_view is true, precompute a view
  that only serves all hits, all-time
* Create if one doesn't exist, refresh if it does
Materialized views quote names correctly

* Allows us to handle odd characters in the view name
  (such as those caused by our own factories)
HitsController can use an all hits, all-time view

* Where the site says it's available via `Site#able_to_use_view?`
* Will previously have been computed as a materialized view by
  `Transition::Import::MaterializedView::Hits`
Replace materialized views rather than refreshing

Slightly slower, but simpler from a deployment point of view to have only one
task that updates the code of the view as well as the view results in one
transaction. If we didn't do this we'd need some kind of "recreate" task as well
as refresh, only to be run when view code had changed.
Clarify materialized view name/purpose in spec

 * Name should reflect why it's there and what we use it for
Change Postgres::Relation.exist? to .exists?

 * Reads better in production code
 * RSpec's BuiltIn::Exist matcher will try both anyway, so no need for
   `should exists`