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

instead of South migrations

This allows for customizing product attributes by using the common
get_class() method.

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.

https://github.com/django-oscar/django-oscar/pull/2019

Since there is no way to override SlugField and AutoSlugField in existing Oscar models, it was decided to pass `allow_unicode` parameter if this setting enable. This allows to achieve backwards compatibility with Django versions under 1.9, when this parameter was not supported yet. If parameter specified in the field expliticly - we do not override it, which allow to control slug fields individually in a normal way. For the reasons, explained above, standard SlugField was replaced with a custom one with the single slight change - control over `allow_unicode` parameter by the mentioned setting.

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

When working on an Oscar project, I noted that the order of the basket
lines was different from the order of the order lines created from that
basket. This made me investigate how exactly Oscar approaches this.

It turned out that Oscar had no notion of ordering those lines. That
means, the order of them was determined by the database. That will work
in most cases, because at least PostgreSQL tends to return them in the
order of creation - but this is not guaranteed. From
http://www.postgresql.org/docs/9.1/static/queries-order.html:

> If sorting is not chosen, the rows will be returned in an unspecified
> order. The actual order in that case will depend on the scan and join
> plan types and the order on disk, but it must not be relied on. A
> particular output ordering can only be guaranteed if the sort step is
> explicitly chosen.

Luckily, Django's AutoIntegerField guarantees that the primary keys are
incremented. So to get the behaviour we most likely want, we just
enforce ordering by primary keys. I also documented how one would go
about switching to an Amazon-style handling. Implementing that is left
as an exercise to the reader.

As a note: I'm not sure what subtle bugs we previously had when applying
offers in the case of the database returning the lines out-of-order.
Let's not fret on it too much, it's fixed now ;)

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.

I was toying with the partner dashboard when I realized the order isn't
consistent. So I fixed it.

It probably would make sense to go through all Oscar models and check
that they have an ordering defined. It should make sense for most of
them.

This also reverts b1477bf

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

Conflicts:
	docs/source/internals/getting_started.rst

Cherry-picked from #1934, because that PR was onto releases/1.1 and I
merged it to there by accident.

I found a bit of time to merge some easy pull requests, so I did. But we
still need to write docs for it, and I'm leaving the work for another
day. Sorry :(

I ran into the issues detailed in #685. Basically, the uniqueness
constraint makes the custom benefit classes a lot less useful. We want
to create slightly altered versions of PercentageDiscounts with
different values, and can't, because we can only ever create one
benefit with the custom class.

I don't see how removing the constraint could cause a problem.

Closes #685.