Upon implementing previous commit, my changes weren't picked up because
Oscar served the SimpleAddToBasketForm. If a user wants to implement
changes in both forms (which is more likely than it is not), the
previous structure meant they had to be duplicated or mixed in. Now, for
most changes, SimpleAddToBasketForm can be ignored.

The templatetag was actually never used in Oscar. See
`django-rangepaginator` for an alternative.

Deprecated in 1.4

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

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 ;)

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

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.

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.

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.