You can't easily create multiple users with the UserFactory without
using a sequence. I also wasn't aware that one can use the nicer
"factories" import instead of "newfactories".

Note that we can't easily use a LazyAttribute for the email address, as
the username may contain spaces.

This approach imitates sending multiple parcels for a defined cost, and
hopefully approximates reality much better.

Note we still make some assumptions about the cost structure to avoid
having to solve an NP hard problem.

This commit also removes the unused max_upper_limit property and
replaces it by a more useful top_band property.

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.

Setting band.charge was accidentally killed in the refactor to the new
shipping method interface, so a correct charge was never returned. This
wasn't caught because there was no test for testing the actual shipping
charge calculation...

Both issues are remedied now. I'll have a more detailled look at the
shipping method tests when getting rid of upper_charge.

TestCase.assertEquals (note the s at the end) has been deprecated.
The only failing tests remaining are CSV related, which is not
surprising.

Without this, it still charges for items that don't require shipping.

Fixes #1138

They were missing it after the recent refactoring of shipping methods.

Fixes #1096

We no longer need to pass the StockInfo instance as the basket has a
reference to the strategy class and can fetch it for itself.  This means
we don't have to break backwards compatibility with Oscar < 0.6.

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

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.

The backported version didn't explicitly create the ProductAttribute
instances before assigning and so they didn't save.

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

This allows updating code in both places, if necessary. Getting Django
1.5 support would be painful otherwise. This also removes the circular
dependency of django-oscar-testsupport on Oscar.

The requirements were merged. The imports were updated
accordingly. Unused imports in the touched files were removed. No
further changes.

shipping/models:ShippingMethod was missing the is_discounted attribute that
exists in the de-facto superclass in shipping/base:ShippingMethod.

Also added a few comments to clarify how they relate to each other, and
tests to check if is_discounted is present on various instances of
ShippingMethods.

Fixes #376

Also split them into unit and functional tests.

This is used by the weight-based shipping method but can be used by
others too.