Use the ideas from fofr's prototype to filter the tag dropdown list

- Use the existing tag list autocomplete functionality (used when we're
  adding tags on a mapping) to autocomplete this text box.
- Leave a comment about having still to work out a way to submit the
  values in the textbox as ?tagged=X querystring, so I don't forget.
Use an existing CSS class instead of inline styles for a list
Limit the number of tags shown to ten

- The default of fifty was getting unwieldy and made it harder to see
  the filter box.
Only show the filter box if there are over ten tags on a site
Submit the data in the textbox as the ?tagged= querystring value

- In order to make the querystring parameter be named ?tagged=, I had
  to name the textbox ID that too, for reasons I don't know.
Add a Cucumber feature to test the new search to filter functionality
Fix the alignment of the button - make it appear next to the input
Fix odd tag indentation by remove list wrapper

* Create a tag list as per the style guide
Use a form with hidden fields to submit tags

* Avoid using inline javascript to submit form
* Based on pattern used by new_url form
* Pre-fill tag filter form with any tags already being filtered by
Add tag field label
Refer to tags as "All tags" in filter field
Style select2 correctly when in an input-group

* Bootstrap 3 styles don’t reset the rounded corners of the select2
list element
Move MappingsProgress into a controller concerns directory

This is the idiomatic place for concerns to live (especially as of
Rails 4) so seems sensible, even though we're not using ActiveSupport::Concern
which would generally be used by concerns which live here.

Having this code in app/ rather than lib/ also means that the dev server
reloads it for us.
Move CheckUserCanEditMappings into app/controllers/concerns/
Convert CheckUserCanEditMappings to our concerns style

This means that we can use it by only calling a method, without
having to include the module explicitly in the controller as well.
Add DisableColumns as a concern

Functionality is the same as it was before, which isn't perfect...

This currently only works when instantiating a new object; fetching
one from the database and then trying to access the disabled columns
doesn't raise an error.

The error raised by ImportBatch.new.type is actually
ActiveModel::MissingAttributeError and not NoMethodError - the test
asserting that NoMethodError should be raised was still passing,
presumably because MissingAttributeError inherits from NoMethodError,
but I've made the test more specific for accuracy.

However, ImportBatch.new.foo *does* raise NoMethodError, so it is
still treating the disabled columns differently from ones which
don't exist in the database.
Also disable columns when fetching from the database
Only use after_initialize to disable columns

Both tests pass without overriding columns(). The only thing I can
find which behaves differently is that when:

- setting a disabled attribute
- saving it
- reloading the object

...when columns() is overridden the column doesn't show up on reload,
and when it isn't overridden the column does appear. In both cases the
attribute can be read after reloading, unsurprisingly.

Since this seems like an edge case and doesn't actually prevent anyone
using the disabled columns either way (which is presumably what we're
trying to do here), let's do less and stop overriding columns() as well.
Rename MappingsProgress module to match filename

Even though we're not relying on autoload here (because these aren't
'real' concerns) it's less confusing to stick to this convention.
Add titles and furls to sites

Sites can already have homepages which differ from their owning organisation's
homepage. Given that the furl attribute is simply a shorter form of the full
URL for a site, it follows that they have furls too.

We are currently inconsistent with how we apply the (new) homepage for a site.
  * If you look at the site in Transition, it says the new homepage is the one
    specified for that site in Redirector.
  * If you visit the old homepage, you get redirected to the site's new
    homepage, which is correct.
  * However, if you visit a page with an archive/unresolved mapping, it links
    to the organisation's new homepage, which is unhelpful or even
    inappropriate.

Therefore, we should change Bouncer's archive behaviour so that it links to the
site's new homepage. To make it consistent, we then need to make it use the
furl (if any) and a title which describes the site, rather than the
organisation. We need to make these changes to support that.