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.

This also reverses the order for the release notes overview. Makes more
sense to me that way.

And create stub release notes.

I had to manually correct the ru_RU django.po file as there were some
mismatching plurals. Not entirely sure what I did was the correct
resolution but it seemed sensible to my non-Russian eyes.

Mention bootstrap 3 dashboard and the customisation of the offer models

We got support for varying the tax rate per product in #1727. This
commit does some follow-up work.

Closes #1727.

This commit adds a bit of documention around the Elasticsearch support
introduced in #1572. It also shuffles around the handler names to be
more consistent.

This was added with #1550.

Building upon the previous commit, we now use ordered dicts for our
search facets.

Specifying `excludes` is deprecated in Django 1.7 and not supported in
Django 1.8.

This order offers the simplest API for common needs - as evidenced by the
fact that the apply_offers crook could be removed from two test files,
saving on imports as well.

That approach is around from sometime around Oscar 0.6. With the
category refactor, it has become expensive to support. I doubt it has
any SEO impact, as e.g. Amazon has product IDs etc. all over their URLs.
@mbertheau seconded this opinion.

I also updated the handling migration section of the general upgrading
doc to use native migrations lingo instead of South's.

Previously, all views handled in Oscar's Application class were
decorated with the permissions_required decorator. That decorator would
not do anything if used with an empty set of permissions, but it
nonetheless seems cleaner to not decorate the views in the first place.

Raised in:
https://github.com/django-oscar/django-oscar-api/pull/2/files#r23832083