Upgrade to paper_trail 3.0.2

This will enable us to fix a bug with recording tag changes.
Don't record non-existent changes to tag_list

We were generating changes for the tag_list when it wasn't changing, we think
this was introduced by the background_bulk_add branch.
Merge pull request #280 from alphagov/dont_record_nonsense_tag_list_changes

Don't record nonsense tag list changes
Don't do DB access in the view: saved_mapping_ids
Move bulk add mappings filters into a module

* Previously, we had to duplicate the same filters across controllers
* Since we're already including the module, make that include happen
  via a method call instead
* That method call passes through the options to before_filter
* Since the use of the filter also depends on find_site, move that
  into the module too
Be consistent in language with other mixins

* acts_as_taggable_on
* has_paper_trail
* tracks_mappings_progress (not the imperative track_mappings_progress)
Merge pull request #282 from alphagov/refactor_saved_mapping_ids_module

Move bulk add mappings filters into a module
Merge pull request #281 from alphagov/refactor_saved_mapping_ids

Don't do DB access in the view: saved_mapping_ids
Narrow the scope to load fewer objects

I believe this could load HostPath hashes for HostPaths on other sites, not
just the relevant one. It wouldn't have updated the Hits on those sites as
the Hits are scoped to the relevant site.
More efficiently update the related hits

Rather than fetching and instantiating each Hit that should be related to this
mapping, just send a single SQL UPDATE to update them all.
Update HostPaths, not just hits on Mapping create
Updating query_params causes refresh

When a site's significant query_params have changed, what a given Hit or
HostPath canonicalises to can change. This means that we might:
* show the wrong hits count for a mapping
* link to the wrong mapping from a hit
* not create new mappings from host_paths

Until now, we've ignored this problem. This change causes the relationship
between Mappings and HostPaths to be cleared and reconnected according to the
new canonicalisation rules. In turn, the connection to Hits is updated.
HitsMappingsRelations can be run for a single site

This will allow Site.update_hits_relations to only refresh the relevant
records, which will be particularly nice if many sites have their query_params
updated at once.
Only refresh relevant HitsMappingRelations

If several sites are being updated, this will drastically shorten running time.
Merge pull request #284 from alphagov/update_hits_relations_after_canonicalization_changes

Update hits relations after canonicalization changes
Stop duplicating status strings for SUPPORTED_STATUSES
Rename SUPPORTED_STATUSES to be http-specific
Add a 'type' column to the three mappings tables

This column stores the mapping type as a word string rather than as
an HTTP status code string. There isn't an appropriate HTTP status code
to use for unresolved mappings, so this is the cleanest way to store
users' decisions about mappings in the long run.

The new column has the same null constraints as the existing
http_status column on that table in each case.

This commit also adds validations for Mapping.type and sets the type
from http_status before validation. The type is not yet being set
correctly everywhere, but all the existing tests pass.
Set mapping type when importing from Redirector
Add a test to document import of '418' mappings

We currently have 198 mappings in production with an http_status of
418, which Redirector used for 'pending content', to signify that
content was coming but was not yet published, so couldn't yet be
redirected to. Bouncer serves 404 for these.