* They are now known as 'stock alerts' instead of notifications.
* They have been moved into the customer app largely (instead of their
  own one).
* The model implementation has been simplified.

This is a squashed, rebased version of the original branch.

Original commit messages:

* product notifications are visible *only* if a product is not in stock
* or does not have a stock record (a new product).
* an anonymous user can sign up for a notification of a product. They
* receive a confirmation link that they have to open to activate their
* sign up. An anonymous user does not have any means of managing their
* notifications in a list. The confirmation email contains a second
* link, however, with a *unsubscribe* link that allows for disabling of
* the notification.
* a registered user can sign up for notifications without having to
* confirm it. When a registered user signs up for a notification, the
* "Notify Me" button disappears from the product information and is
* replaced by a note stating that the user has already signed up.
* registered users can manage (activate/deactivate) their notifications
* in their account settings.
* an anonymous user that has signed up for notifications and creates an
* account will pull in their notifications and have them assigned to
* their account and are then no longer marked as anonymous
* the notifications app registers a receiver for the ``post_save``
* signal of ``StockRecord``. Whenever a stock record is updated, the
* notifications are checked for this particular product and emails are
* sent out. These notifications are then disabled (not deleted) and
* marked with the date the email was sent. This hides the message from
* the registered users account. Notifications are still accessible,
* however, for staff members in the dashboard
* In the dashboard, the ``Customers`` navigation node is extended with a
* ``Notifications`` child that allows for editing, deleting and viewing
* all notifications. It also provides filtering capabilities for them
* based on status, customer name, customer email and/or product keyword.

When top-level categories end with a number, they match the product URL
pattern.  Solved by changing the separator between slug and ID to an
underscore (which isn't a valid slug character).

This uses a few new methods in oscar.core.application.Application which
enable custom decorators to be set for given view fns.

The main use case at the moment is to make it easy to ensure that
checkout is not available to non-logged-in users when
OSCAR_ALLOW_ANON_CHECKOUT is set to False.

tests

Categories are hierarchies, modelled using django-treebeard and the "Materialized Path" model. Each product can exist in multiple categories, with one flagged as canonical (not yet constrained to just one).

Categories can be added to a product with item.add_category_from_breadcrumbs(string)

The string should be in the form of a simple breadcrumb trail, eg:

"Books > Fantasy > Epic"

The string gets split on the '>' character and converted into categories (they get created if they don't already exist.

There's also a CategoryView which lets you browse the products via the hierarchy, doesn't yet support search queries or faceting.

Basket app now uses Application object

removed /item_class/ from product URLs, they don't represent hierarchy so should be done as facets rather than segments

https://code.djangoproject.com/ticket/11559

Completed the models for the order package too.  Added admin files