- Move Oscar app configs into Django app config classes
- Rename Oscar/Django apps' app config module
- Remove "oscar.get_core_apps()" and its app overriding
- Remove "oscar.OSCAR_CORE_APPS"
- Port app forking code to work with Django app registry
- Port class loading code to use app configs to get app properties

* Make it clear that Variants means Parent/Child products

* Clarify when to use variants, and when to use product attributes.

- Remove outdated material relating to old versions of Django
- State that Oscar assumes that the email field is unique
- Update a number of links to Django documentation.
- Minor fixes to other bits of documentation.

Try to make it clearer how these are different from Attributes. Resolves #1776.

Since there is no demo or us site anymore we can simplify the structure
somewhat by moving the sandbox one directory up

Changed "by a admin" to "by an admin"

Fix typo ("An" before a word starting with a consonant)

I was tasked to create a product that would be out-of-the-box available to our users, so I added the attributes in a data migration but I had a hard time finding any resource that describes adding options via code and had to dig through Oscar's code on GitHub to figure this out. People would benefit from an addition like this, at least save time from digging through code to figure this out.

Added usecase for oscar_fork_app command with dot path for forking to project_root dir. 
Added in #1717

Added a reference link of usecase fork_app management command.

I found some docs changes in my git stash that seemed useful. We removed
support for support when removing Django 1.6 support, so we can remove
mention of South.

This fix was supplied in #1686.

Fixes #1686.

I also updated the handling migration section of the general upgrading
doc to use native migrations lingo instead of South's.

This commit removes a few long deprecated bits in the docs and in
code. It also updates the
release notes to include those removals, and highlights what has been
deprecated in 0.8. And it fixes a Sphinx warning when building the docs.

Had to rename to new method name and re-add a link.

Registering receivers is a tricky business pre-Django 1.7 as they get
registered at the same time when models get registered, but require the
sending model to already be in the app cache. It's surprising we don't
see more issues!

Recommendations:
* Avoid calls to get_model in modules that get called during app init at
  all cost
* Don't use get_model in your own code. Just import directly.
* Switch to Django 1.7 :)

This commit probably fixes the issue in #1205. But get_model calls to
fetch the category, product image and stock record will all fail,
because receivers listen to their signals.

This commit also moves the catalogue receiver into it's own receivers
module, because that's how we do it elsewhere. That won't make a
difference to the issues though.

A custom app needs to inherit from Oscar's app config. This ensures the
correct app label, and that any startup code (receivers, etc.) is
executed.
Per the camp ground rule, the fork_app command has been slightly
refactored.

Copy-paste fail.

As it came up on the mailing list again, I've clarified a few more
scenarios of what needs to be done with migrations when upgrading.

This includes two examples for product attributes.

Also fixes two "document not referenced" warnings.

Fixes #794.

The recently introduced management command makes customising easier, and
the docs have been updated accordingly. The how-tos could still do with
updating to the new command, but at least the main docs are current.

These days, to override a mixin it is only required to override the
OrderPlacementMixin; overriding the app and view is not necessary. It is
just a generic case of overriding a core class. A dedicated how-to is
thus unnecessary.

As overriding a core class is the general goal of any advanced
customisation, it has been merged into the customisation section, which
has been given an overhaul as well.

The section regarding modifying apps will be re-added as part of a
higher-level "the Oscar application tree" kind of document.

It's such a core concept, it deserves a dedicated document. Moved some
of the "why" from the how-to into it as well.