Email subscription with filters

This pull request includes work to allow email signup with a list of tags in order to filter email subscriptions. This involves hard coding the list of facets on which drug device alerts can be filtered for email. The mechanism has however been built with other means of getting this facet information via an API rather than the schema.

Trello ticket here:
https://trello.com/c/9cA1JxhB/341-mhra-alerts-signing-up-to-either-drug-safety-alerts-or-medical-device-alerts-5-1

It also includes a piece of work to switch over subscription from using the govuk_delivery_api to using the new email-alert-api, as per this story:
https://trello.com/c/D7GNMvSv/348-swap-finder-frontend-and-specialist-publisher-to-use-new-email-alert-api-3

In order to handle some of the test in cucumber we have upgraded rspec and capybara.

This story is dependent of the deploy of http://www.github.com/alphagov/static in order to pull the new selectable styling for checkboxes found here:
https://github.com/alphagov/static/pull/468
This is actually no longer required and should be removed, my apologies. This was merely added as a means of testing the email signup page before we started work on removing the Finder object from the email alerts page so i could test my regression. The need for this has since been removed as the Finder dependency has also been removed. In which case SOME of this is now a figment of your imagination! :astonished:

The schema however does still exist and my main reason for keeping this is to test explicitly our story here:
https://trello.com/c/9cA1JxhB/341-mhra-alerts-signing-up-to-either-drug-safety-alerts-or-medical-device-alerts-5-1
which is regarding a single format at this point in time. I would have preferred to keep this to cma-cases so at least only one schema is hardcoded however the story did not relate to CM cases and therefore fundamentally felt wrong to test it there. I do agree that the solution isn't perfect but at some point in the future we would hope to remove the reliance on a schema in this way anyway by pulling this information from the content store along with the content. This should hopefully alleviate this .