Add Django 1.7 support

This PR supersedes #1386, but is heavily based on @mvantellingen's excellent work. I've rebased some of his commits and commit messages to produce a cleaner commit history, but hopefully did not introduce any bugs along the way.

The main change is a more explicit approach to not registering models. Instead of basing the models on a custom ``Model`` class, we inspect the app registry to prevent models being registered twice. That approach is slightly more verbose, but feels less magic. 

The other improvement is adding app configs for dashboard applications. They are being relabelled to ``<original_name>_dashboard`` to avoid app label clashes. IMHO, dashboard apps should be moved into their related apps as suggested in #1383; but that's out-of-scope for this PR.

I think about 7 tests are still failing, mostly related to the app fork command and migrations. 

Issues remaining:
- [x] Migrations. Need to create a set of migrations created by the new migrations framework. Need to document how to upgrade. Probably need to drop South from requirements, and add documentation for supported South versions. Should we enforce South 1.0? Need to create a helper script that creates migrations both for South and the new system. Document that one needs to rename ones ``migrations`` directory to ``south_migrations`.
- [x] Decide what to do with ``RangeProductFileUpload``. It's the only model living in dashboard apps at the moment. The renaming of the dashboard apps causes ``get_model('ranges', 'RangeProductFileUpload')`` to fail.
- [x] Need to write detailed upgrade instructions. 
- [x] There is an issue with the new ``get_model`` when called during initialisation; @mvantellingen worked around it in https://github.com/mvantellingen/django-oscar/commit/efdeda525978ca440704b2073fe5ba4d164effb5. Technically, that's a regression of Django, not Oscar. It could be fixed by lazy-loading models if the app cache isn't ready or adding an explicit lazy-loading model loading function, but is referencing models during app startup time even the right thing to do?
- [x] Do we require new tests?
- [x] A few tests still fail, mostly related to migrations. Address.
- [x] ``config.py`` is a non-standard location for the ``AppConfig``. Need to weigh potential confusion against that.
- [x] Document that when forking an app, one should inherit from the Oscar's app ``AppConfig``. The ``fork_app`` command should do it automatically.
- [x] ``get_model`` for Django 1.7 raises a ``LookupError``; previously our loud ``get_model`` raised an ``ImportError``. Should we align those; and if so, how? 
- [x] ``receivers.py`` have been using ``get_class`` to fetch the models. That feels wrong, but using ``get_model`` breaks it. Investigate & document. 
- [x] Do a feedback round with @codeinthehole and @aaugustin.
- [x] Decide if we drop support for Django 1.5. I'd argue for it; while there isn't a good technical reason for it, it gives us a clear roadmap to soon drop Django 1.6, which would remove a lot of special-casing.