get_available_shipping_methods must always return an iterable.

* Document how to customize dashboard forms. Thanks @okfish for providing instruction.

* Fix documentation for `OSCAR_INITIAL_LINE_STATUS`.
Setting value should be defained in the `OSCAR_LINE_STATUS_PIPELINE`, not `OSCAR_ORDER_STATUS_PIPELINE`.

- 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.

* Add note about ``get_default_shipping_method`` shipping repository method to the documentation.
* Add note how to add custom node to the dashboard navigation with non-dashboard URLconf.

instead of South migrations

As per [their blog post of the 27th April](https://blog.readthedocs.com/securing-subdomains/) ‘Securing subdomains’:

> Starting today, Read the Docs will start hosting projects from subdomains on the domain readthedocs.io, instead of on readthedocs.org. This change addresses some security concerns around site cookies while hosting user generated data on the same domain as our dashboard.

Test Plan: Manually visited all the links I’ve modified.

Fix several issues with the CheckoutSessionMixin example given for
using a DeferredTax tax assessment approach:

- Test for submission['shipping_address'] and
  submission['shipping_method'].
- Update line item tax via line.purchase_info.price.tax.
- Refer to shipping_charge rather than shipping_method where
  appropriate.
- Base the shipping tax rate on the tax-exclusive, not tax-inclusive
  shipping charge.
- Fix indentation for the calculate_tax convenience function.

Fixes issue django-oscar/django-oscar#1966.

The demo site was not kept up to date with the recent changes in Oscar
due to time contraints. It should be moved to a separate demo repository
in the future.

This might be resurrected in a separate repository in the future.

django-compressor used to trigger processing of the less files during
development. But with the browser-based compiler, an easy replacement is
available. This even lowers the barrier to altering styles, because
getting npm up and running isn't required.

Offline compilation isn't impacted.

Using the most current less version seems to not cause any trouble, so I
removed the version requirement.

Transactions were improved with Django 1.6; the atomic decorator was
added at the same time. We could've removed this helper earlier, but
better late than never.

There's no extension for it at the moment, but it seems to confuse
users. See #995.

This reflects the change in the repo URL.

Have tested on sandobx site seems all working,
not sure if you need more testing on it.

Fixes #1541.

During many payment flows, the user is able to cancel the process.
This should often be treated differently from a payment error,
e.g. it might not be appropriate to offer to retry the payment.

This exception adds gives us a good way to address that case.

Closes #1528.

Add docstrings to the following classes in 'oscar.apps.shipping.methods':
* Free
* FixedPrice
* TaxExclusiveOfferDiscount
* TaxInclusiveOfferDiscount

Fix typo in 'docs/source/howto/how_to_configure_shipping.rst':
* Change 'shipping.addr' to 'shipping_addr'

This is the squashed version of #1369.

Closes #1369.

Deferred benefits could reasonably make use of that information.

The howto recipe on shipping has been rewritten to describe the new
changes to shipping functionality. The old shipping app reference has
been merged in too to avoid duplication.

- Rework the page on applying taxes in the US
- Update the release notes
- Update the "sandbox" page with details of the new site

Understanding the application tree these days is only necessary when
wanting to change URLs or views. Hence, it's been moved from the
customising doc and reworked into the how-to. This reduced some
considerable duplication and hopefully makes the customisation section
clearer.

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.