So that migrations are not required for changes to the
"OSCAR_IMAGE_FOLDER" setting, for projects that have not forked the
"catalogue" app.

When looking up a URL for a forked app, the previous mechanism fetched the top level AppConfig which allows every user.
The new mechanism creates a dict of dashboard URLs/configs and does a lookup to find a DashboardConfig.

This will also raise NoReverseMatch if the URL does not exist or is not a dashboard URL.

fix https://github.com/django-oscar/django-oscar/issues/3080

- Move Oscar app configs into Django app config classes
- Rename Oscar/Django apps' app config module
- Remove "oscar.get_core_apps()" and its app overriding
- Remove "oscar.OSCAR_CORE_APPS"
- Port app forking code to work with Django app registry
- Port class loading code to use app configs to get app properties

Previously, validation did not pass when current locale is "en-gb" and URL is "/de/catalogue/" and visa versa due to default Django URL resolvers behaviour  - they do not take into account all locales, only current.

The copying of the email address within the datamigration isn't really
optimal when a site has a large number of users and send emails.

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.

Also register the signal receivers in the ready() method for 1.7+

This reverts fa1f8403 which moved them from models.py to __init__.py.
As reported by @mvantellingen, importing receivers from __init__.py
breaks the way models are normally overridden as it causes the core
models.py to get imported before the custom one.

We need to move back to the old system and will need to advise that the
debug toolbar needs to be set-up explicitly to avoid circular import
issues with models.

Fixes #1159
Original issue #1125

Distinguish it from the other folders which each define a category of
test.