This also removes the attr() marking of tests. This can be implemented
in pytest with marking the tests with a custom marker if required.

Previously, weight based shipping methods accepted an upper charge
field. When no weight band matched the baskets weight, this was
returned. I am not aware of a single retailer who calculates shipping
charges like that. It's impossible to pick a sensible value for a
retailer, as there's no upper limit to the amount of items ordered, and
any shipping charges would have to cover costs for that.

Seems ValidationError got a rewrite for 1.6.

Based on http://stackoverflow.com/questions/12384460/allow-only-positive-decimal-numbers

Hmmm, Oscar has a PositiveInteger model field but I suspect we don't
really need it (or should refactor it to use validators).

This (possible backwards incompatible) change means subclassing and
customising shipping methods becomes much easier. Now that shipping
methods are stateless, we can instantiate at compile time and assign
them to the repository instance.

This commit also renames internal methods of the shipping repository
in as the 'prime' notion is no longer valid (as we're not injecting a
basket into each method).

We now need to pass in the shipping charge explicitly as well as the
method. The way that the shipping discounts are persisted is also
adjusted.

This was no longer being used as the checkout code had changed to load
all viable methods and then iterate over to find the appropriate one.

The core API now has an is_tax_known property.

Related to #805

Split into unit, integration etc.

Use charge_incl_tax instead of basket_charge_incl_tax().  This is
clearer.

Backwards compatible versions of the old methods are kept for now.

Related to #805

This makes creating simple shipping repositories simpler as you only
need to override the methods attribute.