Feature/source description split

This PR introduces a split between actual, 'historical' entities and source descriptions (closes #32 ). The implementation is as follows.

Feel free to take over this PR and push commits on it while I am away, if it blocks your progress.

There are two abstract models, as per your suggestion:

Historical is an empty abstract class. It marks historical entities and we can use it to later implement fields that are common to all of them, if needed.
SourceDescription contains fields that used to be in the Reference model and is inherited by source description models. As far as I can see, this class now renders the Reference model obsolete, so I removed it.

The idea is that each entity is represented by three model objects (taking Agent as an example).

AgentBase is the base model that contains all relevant content fields. Also all ForeignKeys (for instance on AgentName) should refer to this model. The end user should not see this, and it has not been included in the Django admin interface.
Agent inherits from Historical and represents the actual 'aggregated' historical entity in our knowledge base. (We need a better term for this 😅).
AgentDescription inherits from AgentBase and SourceDescription and includes a target field that links it to the Agent. This replaces the GenericForeignKey that existed on the Reference model.

This split has been implemented for the Agent, Letter, Gift, SpaceDescription and LetterAction models.

In the AgentDescription admin interface, we can easily select a target for a description:

In the Agent admin interface, connected descriptions are shown in a semi-custom tabular inline.

This PR also includes a migration that is currently missing in develop.

CentreForDigitalHumanities / lettercraft