Reduce tight coupling in GLAMkit model relationships to permit easier customisation

[jmurty]

Look into reducing the tight coupling between models in GLAMkit, especially between more fundamental models (like EventBase) and plugins which should not necessarily be required.

At least, it should be possible to swap out model implementations for portable apps with alternative or derived custom versions. For example, to use a custom icekit_plugins_location.Location model in a project while retaining the FK relationship from EventBase.location.

Ideally even more fundamental models should be swappable without too much work. For example, having a custom derived Occurrence model in a project that adds fields or behaviour to the default occurrence, while keeping intact all the complex interactions in the EventBase-to-Occurrence relationship.

@markfinger suggests:

I wonder if we should replace all the FK invocations in icekit with something similar to Django's auth user, eg: a setting that produces an app/model label. This might help to remove the coupling between the various bits and pieces.

The trickiest part might be handling DB migrations in derived or custom models in a project, without the fairly awful fallback option of copying all existing migrations from GLAMkit into the project.