Hmmm, this turned out to be a monster commit.  This change allows the
basket to be able to correctly calculate prices including tax.

It also requires a whole load of test changes since all baskets now
require a strategy instance to be assigned.

Rather than a StockRecord instance.  This makes it much simpler.

Changes to stock validation are stricter now.

This are to replace the partner wrappers.

Also change attribute_summary to be a property.

This is a tricky one as there were many places that called this method.
It now exists on the availability instance and doesn't require the user
to be passed anymore (as it is already available).

Quite a tricky change for the search index as it doesn't have a
request/user to use for a pricing/availability strategy.  Instead, we
need to enable a *default* strategy that applies to all users in some
sense.

Push logic up into availability class

This is required for offline processes where the request isn't
available.  We need a way of loading the appropriate strategy class to
determine availability.

This method is now deprecated in favour of the session_strategy template
tag.

I had thought we wouldn't need this but it turns out you do in order to
consume/cancel stock allocations through the order EventHandler.

This is better handled using the model's clean method.

Make title a link to update page and the left-most column.

By making the title a link to the detail page.

This requires a formset for stockrecords instead of a single form (which
actually is easier to handle than the previous situation).  We have to
pass the product_class through to the formset forms though which is
mildly tricky.

Improve __unicode__ method for stockrecord.

This is a better way of doing it than using immutable class variables.

This requires changes to `add_product` to allow the chosen stock record
to be passed in.  The various basket properties then use the selected
stockrecord to fetch price information.

This implementation is likely to change to allow tax to be calculated
based on session variables at some point - probably by injecting the
price strategy into the constructor.

This is responsible for picking the appropriate strategy class for the
session and assigning it to the request.

The strategy class then is responsbile for returning the appropriate
price and availability wrappers for a given product.

A template tag is responsible for calling the strategy class with the
product to get the appropriate wrappers needed in the template.