Comment subscriptions

# Why

Handling comment subscriptions in a single place, rather than trying to work
out who we should and should not notify, will improve both our code and the user
experience.

# How

We will store subscriptions in a new model, and automatically create subscriptions when certain events happen.

# What

We will create a new model for subscriptions, and listeners for comments, attachments and changesets. Then we will refactor the comment notification code to use the subscriptions instead of determining recipients.

# Caveats

No UI will be in this branch.

Need to figure out how to handle blanket subscriptions.

# Tasks

## Subscriptions

- [x] db
- [x] model
 - [x] create
 - [x] update
 - [x] delete
 - [x] query
- [x] admin command - seed subscriptions
- [x] alter `CodeCommentNotifyEmail` to use subscriptions

## Listeners

- [x] comments_created - create a subscription for the comment author
- [x] attachment_added - create a subscription for the attachment author
- [x] attachment_deleted - remove all subscriptions for the attachment (should we also remove all comments?)
- [x] attachment_reparented - update all subscriptions for the attachment
- [x] changeset_added - create a subscription for the changeset author
- [x] changeset_modified - update the subscription (author?)
> But why do we need the author?

I started writing a justification for this, but on reflection, we really don't; removed `role` entirely in fdc1a2e98b4ac3d5d1cb2d2a536733833e6f65f2.