travis: Run py.test --cov=oscar instead of coverage run

This also updates the pytest dependencies

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.

Recent babel releases contain several bugfixes.

We only support two versions of Django. That policy might change given
that Django has started doing LTS releases. But for now, it only makes
sense to remove Django 1.7 support.

These are `pillow`, `phonenumbers`, `mock` and `factory_boy`.

This also reverts b1477bf

django-compressor served it's purpose, but given the advent of
more and more frontend JS work, and the accompanying build tools (grunt,
gulp, etc.), it makes less and less sense to use compressor. Jannis
Leidel himself also stepped back from maintaining it.

In my experience with Oscar project, it has also become a bit of a
liability to have compressor as a dependency. Most projects don't use it
any more, but it's not easy to disable/override because all our
templates include it.

So, let's keep things simple and remove it as a dependency. That paves
the way for using other tools, while it's always easy to add back.

See #1791

This also removes the --process-dependency-links argument to pip install
since this was only required for the unreleased version of the
django-tables package.

To support Django 1.8, we are needing a fix in tables2. It is pending a
merge in https://github.com/bradleyayers/django-tables2/pull/245

Let's hope that we'll get a release soon.

Unfortunately, this change requires that we re-enable the deprecated
--process-dependency-links to pip install. I welcome any ideas for a
better approach.

Django issued a bugfix release, so let's run against that.

* Our version of the debug toolbar threw an error, so let's bump to the
  latest release.
* django-nose only has an unreleased version with Django 1.8 support.
  I'm fully in favour of replacing it with pytest, but think it should
  happen outside of this PR. Ping @mvantellingen.
* The latest tables2 apparently contains some Django 1.8 fixes.
  Unfortunately it still breaks, but it's a step forward.

Let's see what breaks, shall we?

Vagrant support was removed from release 1.0. This commit removes mentions of it from the docs.

Closes #1559.

There was a recent security update for Pillow (to version 2.7) that this
will allow.

We hit the 1.0 milestone and generally consider it production-ready.

This allows testing against the installed package instead of the 
version controlled source.

Part of #1569

Oscar is becoming a more community-owned project. This commit reflects a
few organisational changes taking place.

This reflects the change in the repo URL.

A bugfix release for 1.7 was released which contains many migration
fixes. Also bumped the minimum 1.6 version as we were already lagging
two releases behind.

This is to avoid https://github.com/nvie/pip-tools/issues/50 so that
pip-compile (from pip-tools' future branch) can be used to pin
dependencies. See also http://nvie.com/posts/better-package-management/.

The problem is detailed in #1480. We need to require Haystack > 2.3.1 to
avoid it clashing with our support for Django 1.7.

Oscar 0.7 works ok with later versions of these two packages and so we
open up the restrictions in setup.py to avoid forced downgrades for
Oscar projects.

Fixes #1477

Haystack 2.2 contains a lot of bugfixes, including a fix for Python 3.
It seems like we'd do everyone a favour by upgrading.

Security fixes mean both a new Django 1.6 and Django 1.7 version.

This is how we normally do things.

Factory Boy got a new syntax in 2.4, and was released a while ago. As
Oscar's test factories are semi-public API, it's a nice gesture to
upgrade.

* django-extra-views 0.6.5 added a pinned version of six, which causes
  issues with other dependencies that install a different version. A fix
  is already on master, but it's easier to limit the range for now.
* Haystack 2.2.0 was released and looks safe to use with Oscar. I'll
  allow that for now, but in general we should probably limit the amount
  of versions we support.

We only needed it because Django 1.4 shipped with a pretty old version
of six. Support for that has been removed, and Django 1.5 ships with six
1.6.1, which is more current than we required.

This nicely avoids an issue with django-extra-views pinning a six
version which caused the sandbox build to fail:
https://travis-ci.org/tangentlabs/django-oscar/jobs/32223978#L971

As Oscar depends directly on tables2 now, it should be returned as part
of get_core_apps, and has been removed from the requirements.txt and
INSTALLED_APPS calls.

This catches a call to unicode() and removes the unnecessary future
import for the print function.

They are both used in oscar.test, which means it's "public Oscar API".
Deployments might rely on e.g. the factories for their own test suite,
so all needed dependencies need to be installed as part of Oscar.

factory-boy 2.4 brings some nice, but breaking API changes.

The missing dependencies were discovered when working on
django-oscar-datacash, where some of the old-style factories are used,
but newfactories gets imported into that namespace.

South does not work with Django 1.7, so we shouldn't install it and
require an explicit decision by the user.

Oscar's policy is to support two versions of Django. So while there
isn't a major reason to drop support for Django 1.5, dropping support
for Django 1.6 once 1.8 is released will reduce complexity considerably.

This crude and destructive script helps create migrations for both South
and Django's native migrations framework. I'm happy to leave plenty of
room for improvement so that the King of Bash (aka @codeinthehole) can
do his thing.

This commit also enforces South 1.0. It's a backwards compatible release
which explicitly is meant to help the migration; it makes both our and
our users life's easier. Notably, it first looks for a south_migrations
directory before falling back to the migrations directory in an app.
That nicely avoids any conflicts between migration files between the two
migration frameworks.

It is now required for both Django 1.7 and Python 3 support. To keep
things simple, we now require it across the board.