Explicitly distinguish between standalone/parent/child products

Previously, the product "structure" has been determined implicitly. That
means that the decision if a product is a parent product or (what used
to be called) a variant product was made by looking at it's parent
field. This makes it harder to reason about it in edge cases, especially
when creating a parent product before creating child products.

This commit introduces a field to be able to explicitly set the intended
product structure. It also starts down the path of consistently naming
products either stand-alone, parent or child product.

Previous names for those products existed, but they have slight issues:
* "Canonical" will be an unknown word too many non-native English
  speakers. It also reminds of the makers of Ubuntu.
* "Group product" does not express that there's a hierarchy
  between parent and child products, and it's not clear to which level
  a group product belongs.
* "variant product" in itself is fine, but expressing the hierarchy by
  using "parent" and "child" is preferrable.
Introduce properties to use new product structure field

These are short-cuts to reason about a product's structure.
Deprecate old product properties

They use the old, implicit way of reasoning about products, and don't
confirm to the new naming scheme.
Update and broaden product validation

The clean method now uses the new API.

A docstring indicated that parent products can't have
stockrecords. Added a check for that.

Also added a check that child products must have a parent.
Use explicit product structure in ProductForm

This commit makes the changes in 4f709cd58 slightly less hackish, as we
now have an explicit field to use to reason about the product's
structure. Nonetheless, we still inspect raw POST data to decide if the
attribute fields are marked as required or not.
Update codebase to new API

Those are mostly cosmetic changes.
Get tests to pass (excluding DeprecationWarnings)

I'd like to move away from django_dynamic_fixture, factory_boy is so
much nicer.
Update strategy interface to new naming

This breaks more backwards-compatibility, but is an unfortunate
necessity to be consistent with the new naming.
Fully migrate codebase to new API

Tests now pass and no deprecation warnings are thrown. Beautiful.
Merge branch 'master' into product-naming

Conflicts:
	oscar/templatetags/purchase_info_tags.py
	oscar/test/newfactories.py
Redo product structure migrations

The previous commit merged master into this branch, and added a
migration for the catalogue app. The version numbers conflict, so it
seemed easiest to just redo the schema and data migrations.
Add release notes for product structure changes
Rename a few more tests and comments

This is the result of wild grepping through the codebase. Nothing too
exciting to report, really. create_product now sets a products structure
to 'child' if a parent is specified.
Rename all of strategy's methods

This was somehow overlooked. Also added a missing
parent_availability_policy on the Structured base class.
Merge pull request #1379 from tangentlabs/product-naming

Add explicit product structure field & consistently name product structures