Since the recommended way to override models within an app is to add
‘from oscar.apps.order.models import *’ we need to limit what is 
exported otherwise subtle bugs may occur in the users code.

Simply defining __all__ [‘Model1’, ‘Model2’] doesn’t work since Django
will raise an AppRegistryNotReady exception for all models listed in
the __all__ list but are not available. Dynamically building the list
solves this.

That puts it in line with Oscar's naming conventions.

This is necessary, as Django 1.7 enforces that a model can only be
registered once. Previously, declaring a model a second time would lead
to the second declaration being silently ignored.

The changes have been automated by this gist:
https://gist.github.com/maikhoepfel/05e047e0205f576da1a6

In Django >= 1.7 this will be done via the AppConfig

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

This is to avoid circular import issues as most receivers.py modules
also import models.  It's not entirely clear what circumstances are
required to get the circular import - it seems to be when using
django-debug-toolbar>=1.0, which changes the way the URLs are
monkey-patched.

This changes adopts the recommended practice for importing signal
receivers:

- https://groups.google.com/forum/#!msg/django-developers/PReHoxwwG_c/M-asj72ks7YJ
- http://stackoverflow.com/a/14192257/25517

Fixes #1125 (I think)

Analytics allows tracking of user and product activity.