Models

@wesleykendall This pull request includes the models for `entity_subscription` and a basic readme of the semantics of the models.

I tried to be very careful in the readme about explaining the difference between "source" and "medium" both from the perspective of a user receiving notifications, and from an application developer creating/sending notifications. Let me know if the readme is clear on that front. I think maintaining this distinction is key to keeping a flexible subscriptions app.

This pull request does not include any of the rest of the API for working with subscriptions. Those functions will be developed in tandem with emails and notifications.
I've thought about this. It might. I think there are two reasons why you may not want this.

1. If an entity has a relationship with super entity "X", but then that relationship is now changed to be to super entity "Y", they could start receiving notifications that they don't want.
2. If there are overlapping subscriptions, an entity would have to unsubscribe from both of them.

Unsubscribing directly from a medium/source combination has the benefit of circumventing those issues at the cost of a lack of cascading deletions. Do you think those circumstances are rare enough to tip the scales towards a FK to Subscription?