When adding a migration on master, I discovered that the new-style
migrations were strongly out of sync; Django wanted to create new
migrations for almost every app. That was surprising given that no model
changes were made since building that set of migrations.

The issue is that they were built with Django 1.7 RC2, and we've since
switchted to RC3. If I'd have to guess, I'd say the following issue is
responsible for it:
2da20379c0

As beta 1 is only a day old and it doesn't cause major headaches, it was
decided that it's easiest to release a new set of migrations. And pray
to the gods of Python that we won't have a similar situation again
before the Django migrations framework stabilises.

Native migrations created with Python 2 differ from ones created with
Python 3. More importantly, they failed when used in Python 3, but not
vice versa. This is caused by field names being marked as byte strings
when using Python 2.

This rewrites the native migrations, which probably isn't a bad thing
either, because they were created with a pre-RC2 version of Django, and
Django 1.7 has since seen a few more migration-related fixes.

It's likely Django now does the correct thing and generates Python 2 and
3 compatible migrations under both versions of Python.

To create test databases, the Django test runner calls the 'migrate'
management command, and I think the current Nose test runner calls
'syncdb', which under Django 1.7 is aliased to 'migrate'.

This command inspects the migration graph to figure out the migrations
to run. So it inspects the migrations that ship with Oscar. Some of them
depend on the partner or customer migrations. The test suite swaps out
those apps. Until now, the command then couldn't find the initial
migrations and would fail with a dependency error.

As far as I can tell, there's no good way to just call what used to be
"syncdb" and ignore migrations completely. So for now, we will have to
create migrations for the test apps that replace Oscar.

New style migrations created with the helper script. Now doesn't detect
any more changes after this set has been applied.

This change might need to be re-applied if more migrations get added
before this PR is merged into master.

More changes need to be done regarding migrations; this commit just
moves them out of the way so that Django doesn't pick them up.

The initial one is for the releases/0.1 branch - any others are to
handle changes in the 0.2 branch.