Less noise in dashboard product list

* Product status has been removed as field, and hence can be removed as a
  column.
* The list now doesn't list child products individually. This suits the
  anticipated workflow much better, and better shows how child products
  are dependant on their parents.
* Parent products can't have stockrecords, so show a minus instead of 0.
* Standalone products can't have children, so show a minus instead of 0.
Use get_title() for product delete view

The product delete view doesn't use get_title() for the child products.
Hence it potentially shows empty titles. Showing identical titles is at
least slightly less confusing.

It also uses get_title for the title of the deleted product, because one
might use the view to delete a child product.
Filter product update template by product structure

Several sections are not applicable for products of a certain structure.
Hence, they're naively hidden by hiding them in the navigation.
No further hiding is done to ease customisation of what gets shown, to
reduce redundancy and to reduce the chance of the nav and the actual
section display logic getting out of sync.

It's recommended to view this commit with the ignore-whitespace option.
Allow deleting child products from parent product edit page

Child products can now be deleted from the variant section. The redirect
logic of the delete view had to be adapted to this new use case.
Clarify product class handling

The docstring table was wrong; child products inherit their product
class. To make that more epxlicit, the get_product_class method has been
updated.
Implicit product structure: Simplify product form

For the sake of a good UX, product structure handling will be hidden
away from the user. Instead, the following behaviour will be implemented:

* A newly created product defaults to being a standalone product.
* Child products can only be created from the variants section of an
  existing product. When that happens, the existing products becomes a
  parent product.
* When the last child product is deleted, the parent product is marked
  as a standalone product again.

Note that this implicit behaviour will be reserved to Oscar's dashboard
views, because it purely exists for a good UX. It will be easy to
override to ensure that more advanced scenarios are still possible.

This change simplifies the logic that is needed in ProductForm, which is
implemented in this commit. Product structure is kept as a hidden field
to ease ajax'fied dashboard editing.

Note that prior to this commit, ProductForm set the product class on
child products even though child products inherit their product class
from their parent. The old get_product_class method would also return
the wrong product class.
Implicit product structure: Handle creating and deleting

This is the easy bit. Product structure defaults to standalone product
when creating a product, and reverts to standalone product when the last
child product is deleted.
Beef up ProductCreateView to handle creating child products

A third way to use the view has been added: when called with a parent's
primary key, the view now handles the creation of child products. It
passes the parent into the context, so that both when creating and
editing child products, the template can hide most of the fields.
Prevent adding child products to products with stock records

The implicit conversion of a standalone product to a child product only
works if certain conditions are met. As far as I can tell, the only
condition preventing a conversion would be when the product already has
stock records -- parent products aren't allowed to have any.
Pass validation and improve workflow

Variant products can now be created from a suitable future parent
product. A helpful message is displayed if the future parent is not
suitable.
Two new paths have been added to handle adding a variant from a suitable
parent, and for adding another variant after saving one.

Some more tweaking was required to pass the tight product validation.
Wrap is_discountable for child products

At the moment, we don't support setting is_discountable for child
products individually. This does keep things simpler when editing
products. If a use case crops up, it should be reasonably easy to
change.
Revert to rendering all fields of product form

This saves one step when customising the product model. Instead, we
dynamically delete the fields not needed for child products -- that's
the cleaner approach anyway.