It's easier understood by the everyday person than product class.

Tried to have consistent capitalisation. "Product Type" when used by
itself, "product type" when used in a sentence, apart from when used
in the beginning of a sentence ("Product type...").

* It can now be specified in OSCAR_DASHBOARD_DEFAULT_ACCESS_FUNCTION
* nav.py and menu.py were split up so that Node can be dynamically
  loaded and hence overridden

I recently needed to alter the access function and realised it's not as
easy as I thought.

Allow using a different app than promotions as the homepage view.

I was testing this with adding a rating facet to the sandbox.  This
works ok but lots of products don't have a rating and so don't appear.
The syntax for getting Solr to select docs without a facet is geniunely
annoying and hard to get Haystack to do it.  I gave up.

Ticket #1127 correctly mentioned that we can't use Django's
get_user_model to register signals:
https://docs.djangoproject.com/en/1.6/topics/auth/customizing/#custom-users-and-signals

This commit rewrites the affected migrate_alerts_to_user receiver to
just happen in Oscar's AbstractUser save() method. This works upwards of
Django 1.4. For Django 1.4, a receiver must be manually registered to
the correct User model.

Analogous to the settings for the basket cookie, the cookie that stores
the recently viewed products is now configurable.

Fixes #1064

This reverts commit 7075ba6594.

These classes have been removed in favour of the new search structure
developed for Oscar's demo site.

This setting never did anything. Added documentation for it being
dropped.

Babel tried to guess it from the LANG environment variable. But that's
not set in all environments, and would lead to an error in those cases.

Fixes #837

Introduces the concept of a "feature" that can be hidden. A list of
features to hide can be supplied in OSCAR_HIDDEN_FEATURES.

Feature hiding is currently supported in two places.
Application instances can carry a "hidable_feature_name". If set and
found in OSCAR_HIDDEN_FEATURES, post_process_urls will return an empty
set of url patterns, hence disabling relevant views.
display_tags also has a new template block tag iffeature.
{% iffeature "feature" %}xxx{% endiffeature %} will hide everything
inside the block if the feature is hidden.

Fixes #713

Since variables were required to be passed in, this forced evaluation of
the i18n string which caused a circular reference when Django started
up.

This isn't a permanent solution - just a workaround until search gets
the a reworking.

They weren't using dicts for parameters to work around the ordering
issue.

This supports range facets specified by "facet queries".

Plus some general reorganisation.

The AccountSummaryView was trying to do too much and included random
bits from the other views. It has been changed to a simple
RedirectView. The redirect target can now be set with
OSCAR_ACCOUNTS_REDIRECT_URL and defaults to the newly-introduced
ProfileView. This leaves the UX unchanged apart from the fact that
was used to be scripted tabs is now separate views.

There was a lot of template duplication between the separate views. I
have introduced a PageTitleMixin and used this to significantly reduce
redundancy (e.g. hundreds of lines). This also led to removing a few
slight inconsistencies regarding headings, breadcrumbs etc.

The new templates have been categorised in subfolders.

Apart from the new ProfileView, I've had to introduce a simple
ProductAlertListView. I've also upgraded the ProductAlertCancelView to
be useful for both canceling from emails etc. as before, but also from
the ProductAlertListView.

Now I can define new blocks under settings.py, without needing to overwrite an application.

OSCAR_REQUIRED_ADDRESS_FIELDS allows setting which fields are required.
The use case is that post codes are expected to be required, but many
countries don't actually use them.

Now I can define new blocks under settings.py, without needing to overwrite an application.

Upgrading pyflakes meant the number of violations jumped above the
failure threshold.

Also added a few more warnings to the ignore list.

Without this, a silly quantity of 9999999... can cause database
integrity errors when submitted via the basket form.  We set a sensible
maximum value to prevent this.

Fixes #278

Apparantly mortals can only hold 7 items in their mind at once; any more
and they get confused.  Hence this change condenses the nav down to 7
heading items with some previous items being folded into the child
nodes.

The order of the nodes has been altered too, according to the wishes of
Tangent's UX team.

Fixes #446

Replace the import-time nav set-up with a settings-based one.  This is
more flexible ultimately although it doesn't allow extensions to easily
add their node automatically.  However this is probably a good thing
overall as it isn't easy to remove nodes in the previous impl.

Fixes 426

* 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.

Also split them into unit and functional tests.

To make it trivial to change the logo and branding without forking
templates.

Updated templates to use it.