Ensure product class is available in template

Without this change, it's not available when creating a new product.
Prevent attribute validation for parent products

This is a messy situation caused by Oscar's product update view trying
to handle too many different scenarios.  This fix is quite hacky and not
entirely watertight - a better fix will arrive as part of #693 when the
catalogue dashboard gets rewritten to have separate views and forms for
group and standalong products.

The core problem comes from trying to validate required attributes.
When you are creating a parent product that belongs to a product class
with required attributes, you don't want to enforce that the attributes
are set (eg the parent doesn't have a size).  Before this change, the
dashboard would not allow a parent product to be saved if it didn't have
the product class attributes set.

Hence we need to change the validation rules when the form is submitted,
but it actually impossible to tell exactly if the submitted data is
for a new group product or a standalone product with no stockrecord.  To
address this, a new is_group field has been added to the form to
allow the validation rules to be altered when entering a new group
product.  Also, the product's save method allows a new kwarg that
disables attribute validation - this is required when saving a parent
product.
Adjust product update template

- Ensure variant overview shows attributes
- Use form field partial where appropriate
Updates setup.py to allow django 1.6.x
Incompatability with Django 1.6, commit_on_success and sqlite3

Changes to the transaction handling in Django 1.6 resulted in
the ``commit_on_success`` decorating failing with SQLite3.

The `atomic` decorating is used instead when available.
Don't render blank table in categories dashboard
Improve catalogue admin for options
Add fixture for creating a variant product

And load it for the sandbox by default.
Extend strategy class to work with variant products

The strategy API has gained a new method: fetch_for_group, which is for
fetching stock information about a group/parent/abstract product.  Like
the existing fetch method, this is highly customisable.

For a group product, we fetch all relevant variants and stockrecords; we
then pass these to the methods that determine availability and pricing.

The pricing display logic for a group product has been simplified a bit.
We now just look at the first stockrecord and use that price - we no
longer say "From £X".  This seems to be a more common pattern in the
wild and allows the templates to be simplfied as they no longer need to
handle group and standalone products separately.
Ensure that only available variants are in basket dropdown
Use a custom widget to show unavailable variants in dropdown

We define a custom select widget which allows certain choices to be
marked as disabled.  We use this to include unavailable variants in the
add-to-basket dropdown.
Correct variant fixture loading in makefile
Adding missing packages to requirements_demo.txt
Added missing datatypes
Fixed offers fixture
previous failed with
'sites/demo/fixtures/offers.json': Cannot set values on a
ManyToManyField which specifies an intermediary model.  Use
offer.RangeProduct's Manager instead.
applies_to_tax_exclusive_prices  has been removed
Bring templatetags inline with earlier renames
commits:
a8a140fa94baa13f778f9a1529de8d5c2b75e3f2
6341b576bf9fa18c4dc1c78aaa88e174826763f6
Added DATACASH_CURRENCY="GBP" to the settings.py
needed by django-oscar-datacash
Permission-based dashboard: Don't mask ImportError

get_classes hides ImportErrors that are part of it's discovery strategy.
Only ImportErrors that are thrown when an app exists are raised by
get_classes. Those are the ones that previously were masked by
_default_access_fn's blanket exception. Now we don't catch ImportErrors,
so they should propagate properly and give a meaningful stacktrace.
Use context manager for catching warnings in runtests.py

I could never reproduce the DeprecationWarning thrown by Travis, e.g. in
https://travis-ci.org/tangentlabs/django-oscar/jobs/15324179
As far as I understand the warnings module, the previous code to
escalate DeprecationWarnings to exceptions should have had no effect.

With these changes, DeprecationWarnings get thrown correctly *if* used
in a single-threaded environment; both locally and on Travis.