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.

It's getting easier and easier to customise parts of Oscar; the
customisation section can do with a rewrite because of it. Added to my
to-do list.

The function essentially does two things:
1. it applies a prefix - the first argument - to the given urls. In no
   instance a prefix was given
2. it calls url() for simple tuple or list elements in the given iterable.
   Cases where such a tuple or list was passed to patterns have been
   replaced by direct calls to url()

2 allowed for both calls to url() and simple tuples to be listed in
get_urls() and similar places. This allowed for unnecessary variation.
Always calling url() makes the url lists look less noisy and more uniform,
allowing the reader to focus on the actual differences of the urls instead
of superfluities.

django.conf.urls.patterns will also undergo deprecation starting from
Django 1.8. This commit anticipates that change.

https://docs.djangoproject.com/en/dev/releases/1.8/#django-conf-urls-patterns

The new recipe has a working example on customizing the behaviour Oscar
does when a customer places a successful order.

This is pretty much what I use for bikepartsmarket.com. If this gets
some more eyeballs, it might mature enough to move into Oscar core.

Fixes #1266

Just crossing items off my bucket list.

It's a nice app to handle non-blocking email sending.

Two links needed to be corrected.

The customisation section required some changes as it's not often
necessary to override the root application instance to change URLs or
views of subapps.

Those documents lived in ref/, but really aren't reference documents.
Topics/ is a more appropriate place for them.

With details of new prices/availability structure.

* Better wordings for the individual steps
* Mentioned necessary copying of migrations directory
* Fixed wrong prerequisites in examples
* Glossary typo fixed

The mailing list raised the issue of having to include the models.py to
replace a Form. The docs weren't clear, so I've taken the opportunity
to:

* merge 'INSTALLED_APPS' section and 'models.py & admin.py'.
* change misc wordings and add clarifications

It's a great idea, but confusing when empty. Replaced by links to
how_to_customise_models which contains some explanations.

Attempt at making it clearer what needs to be done for what kind of
customisation. Created a new topic that lines out the prepatory
steps that need to be taken, and moved duplicate information from the
how-tos into the new topic.

The old howto included out-dated info on how to translate Oscar. That
has been replaced by a link to the Transifex project.
It was the only howto left under the Contributing headline, which really
shouldn't be there (as there's an entirely different section in the docs
for contributing). As it is more of a topic anyway, and will hopefully
soon include documentation on translation style etc., it was turned into
a topic.

To set a base for upcoming docs changes, the docs directory structure
has been streamlined to follow a simplified version of Django's docs.

The old _draft folder has been removed. Both files from there and the
current docs that don't fit nicely into the new structure are in _old/
for the moment.