Move API to normal Rails

While hexagonal architecture is fine in principle, the complexity of the abstraction was getting in the way of delivering important bugs/features, namely:

- Queuing on the notification side of things - our external API partner typically returns a response in ~10 seconds, which is [unacceptable to downstream clients of our API](https://trello.com/c/G7bmYRkT/378-email-alert-api-times-out-regularly)
- Emails were being sent to [all topics we knew about](https://trello.com/c/Zbyhoudv/379-email-alert-api-appears-to-send-email-to-all-topics-rather-than-the-selected-ones), rather than just the specific tags that were sent

This pull request, almost entirely by @elliotcm, rewrites the application as a standard Rails application, and as a bonus implements queuing using Sidekiq and fixes the topic bug.

**Note**: this will require merging a [separate PR in gds-api-adapters](https://github.com/alphagov/gds-api-adapters/issues/232) to fix the URL namespacing that's changed (from underscore separated to dash-separated), and careful deployment (we'll want to wipe the database before deploying, as the migrations and schema have changed).

I recommend checking out the code and running it to test this - reading the diff is going to be hairy.
I hadn't realised that was the intended semantics; I can't think of a rename for the method that would convey those semantics clearly, so perhaps adding a code comment would be good.  Having looked at the caller of this method, I see why those semantics are wanted, and this implementation seems right.