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.

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.

* 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

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.