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.
Update tests and release notes for updated child product editing

Nothing major to see here. Improved the slightly horrid
TestCreateProductForm test class.
Refactor page title handling into own method

It's not unlikely that a custom deployment would like to change the
title handling. Also adds a more sensible title when editing child
products without a title (instead of showing the parent's title).
Adjust URL for creating variant product in dashboard

Why?
- s/_/-/
- I try and follow a RESTy approach to URLs where the parent identifier
  is to the left of any action or subordinates resources. (I'm sure
  there are other examples in Oscar where we don't follow this).
Move info block about editing a variant

I think the top of the page looks better than the left-hand navbar. It
avoids the mild spacing issues it had there too.
Improve headings/titles on product delete page

For variants, there was a missing breadcrumb and the wording made it
sound like you were deleting the parent.
Fix bug with handling last child deletions

This change:

- Alters the logical flow so the deletion of products takes place in the
  `delete` method rather than `get_success_url`. As per SRP, I don't
  think the `get_success_url` method should write to the DB.

- Fixes a logical error around child product deletions. We need to test
  if the product being deleted is a last child *before* deleting it as
  this changes the result.
Don't set a product class in child products fixtures

@codeinthehole discovered a "bug" when trialling the changes in #1441:
https://github.com/tangentlabs/django-oscar/pull/1441#issuecomment-52473882

Pleasingly, the error is just a sign of the validation doing it's job.
The variant product fixtures still had a product class set for child
products.
New success messages for child products

If a child product did not define a title, the success message for the
updating the child product and the message for it's parent were
identical, as get_title() would just use the parent's title. That can be
a bit confusing, and has been addressed in this commit.