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

Those are needed to support the new migrations framework:
https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#field-deconstruction

I think I'm doing the right thing. But I'm not entirely sure.

The metaclass definition did not work with Python 3, to_python wasn't
called. Documented in:
https://docs.djangoproject.com/en/dev/howto/custom-model-fields/#django.db.models.django.db.models.SubfieldBase

Also clarified logic of the to_python logic.

A lot of Oscar's models have slugs that are populated from other fields
in the respective save() methods.
But currently there's no logic to check for duplicate slugs.
AutoSlugField does both the population and ensures uniqueness.

CharField that stores '' as None and returns None as ''
Useful when using unique=True and forms. Implies null==blank==True.

When a ModelForm with a CharField with null=True gets saved, the
field will be set to '': https://code.djangoproject.com/ticket/9590
This breaks usage with unique=True, as '' is considered equal to another
field set to ''.

Discussion around #1200 highlighted that we must be aware of differences
between the versions of six that Django ships and the one we use.

In general, the external version of six is the best choice for Oscar,
because it allows to depend on a specific version of six. The multiple
Django versions we support each come with different versions of six,
which makes it unattractive to depend on them.

When interfacing directly with Django, it should be decided on a
case-by-case basis if it's more appropriate to use Django's supplied
version of six or the external one.

In the case of the UppercaseCharField, Django clearly documents what
needs to be done to get it to work with both Python 2 and 3 in
https://docs.djangoproject.com/en/1.6/howto/custom-model-fields/#the-subfieldbase-metaclass
Those instructions are the same for all versions of Django we support.
Hence it's been decided that it's best to switch to Django's recommended
way of declaring the metaclass, and using Django's version of six for
it.

Using standalone version causes issues. Fixes #1200

Plus ensure the copyright notice is correct for the modified phone
number work.

Ran through the codebase with pyflakes. It caught one missing
ImproperlyConfigured import.

There's no security issue with checking local URLs.

The to_python logic of the field was not actually executed as the fields
meta class wasn't set. That's also the reason why AbstractAddress
explicitly called upper() again, which is redundant now that it works.

This is better handled using the model's clean method.

This is necessary for South migrations. As it doesn't define any new
parameters, an empty ruleset is all that is needed.

Plus reorganise tests

Please note that ExtendedURLFields's verify_exist does not
default to True anymore.

There is now a model field, a form field and a validator.