Add a inital frontend for email subscription

Tweeked the styling of the button mixin to make the text more central to
the button.

Added JS to add new rows but this will want a server-side equvilent. It
is implemented as a proper form element so this can happen.
Move home#email_signups into email_signups#show

This'll pave the way for having a proper model to represent the email-signup.
Add placeholder EmailSignup model and start using form helpers

EmailSignup pulls in enough of ActiveModel to be used in form helpers, also validations which we'll use later to make sure the user choices are valid.
Pull down translations, don't fetch world locations

World locations aren't used and the translations speed up the page.
EmailSignup has alerts and is not valid if there are none

Also, not valid if any of the alerts are invalid.  We use the alerts from the email signup instance to generate the form too.
Alerts are valid if they have a topic, and it's a real one
Alerts are valid if the organisation is present and a real slug
Alerts now require a document_type and for it to be valid

Renamed from content_type to document_type, made EmailSignup be in charge of what document types it allows.  This does involve a slightly hacky use of a DocumentTypeOptionForAllOfType class that only exists to allow for labels and slugs to exist for the "all" option on a per-type basis.  These objects share enough of the API of the PublicationFilterOption and AnnouncementFilterOption objects that we can use them interchangeably - where we are using them, in this UI.
Put the .alphabetical on topics into EmailSignup

The doucment_type and organisations already do sorting (explicitly and implicitly) so this might as well too.
Tweak the form elements for the alert objects

1. put an index on them (this will end up generating a hash instead of an array, but it'll mean the ids and names are actually unique).
2. pass in the topic, organisation, and document_type to the helpers that generate the options for the selects.
3. show any errors from the email signup or alerts
Make the duplicate-fields js code common for use in frontend and admin

It's now broken up a little so we can reuse the part that iterates over form elements and renumbers them if they have a blah[<idx>][blah] style names.  We do this so that in the email-signup js we can properly duplicate the alert fields.
Expose more feed_urls to govdelivery for an edition

1. We need to add the publication_filter_option and announcement_filter_option params into the mix for publications and announcements.
2. We need to produce a url for each combination of org, topic and any filter option (including the empty combination).
Create EmailSignup::FeedUrlExtractor to turn an alert into a feed_url
Provide EmailSignup::TitleExtractor to get a title for an alert

When we talk to the govuk_delivery client to get a topic, we need to give it a title incase the topic hasn't been created already.
Break email signup into multiple files for ease of reasoning about it
The final piece of the puzzle: url for redirecting the user to sign up

This is a bit weak, as it's relying on functionality that hasn't been built yet:

1. the api adapter returns the http response when we ask for a topic, it will at some point return an object or some kind (just ignoring this for now as we don't really use the return value in our code)
2. the api adapter doesn't have a method to ask for the new signup url (have handled this by patching on the method we want with a fake return value)
Wrap it all up in the controller

If the email signup is valid then we take the first (and only the first) alert and redirect the user to the new signup url for that alert using the EmailSignup::GovUkDeliveryRedirectUrlExtractor.
For now, you can only sign up to one alert at a time

When the gov uk delivery api can support signing up to multiple topics in one form submission we should only let users create one alert at a time.