Improve AddToBasketForm

Wowsers! This form must be seriously old - it still refers to products
as "item"s which was dropped from Oscar at about week 3. So it's overdue
a refactoring.

This change alters the constructor signature to not require the request
as that's a nasty codesmell as forms shouldn't know about the request
directly. The request is replaced by passing the basket - the strategy
instance can be accessed of the basket anyhow.

I've renamed the kwarg "instance" to "product" and fixed the callers.

I've also reordered methods in a few classes to roughly follow the
normal order of execution. I find this helps to understand classes you
haven't seen for a looooong time.
Add simple tests for AddToBasketForm

Plus some comments on why things are the way they are in the form.
Tidy basket views

I've become slightly obsessed with methods being listed in the approx
order that they get executed.
Add test factories for products, partners and stockrecords

This is part of the long-term move to use FactoryBoy for tests.
Adjust AddToBasket form to require purchase info

This means we don't need to do the law-of-demeter-violating call to
fetch the purchase info for a product (line 79 of forms.py). HOWEVER,
I'm starting to have second thoughts about this - I've discovered that
the adding to basket process is quite confusing for variants and I
intend to refactor.

This commit also adds some useful tests though so it's a valid stepping
stone to a better place.
Use sequences for unique fields in factories
Fix bug with variant AddToBasket forms
Restructure add-to-basket form and view

This is quite a large change. It:

- Alters the add-to-basket URL to have the "base" product's PK in it
- Changes the constructor of the AddToBasket form to not require
  purchase_info (even though I only just introduced it!)
- Renames the product_id field to variant_id and only uses it for group
  products

These changes are motivated by the variant workflow. Before this change,
you effectively had different forms being used for rending and
validation as the product being passed to the form constructor was the
group product when rendering but the variant when validating. This just
about worked but was not nice.

The purchase_info param is removed as we can only calculate the
purchase_info once the variant product has been validated. Hence we
again violate Demeter and make a deep call to the purchase info
calculation within the basket form. Might revisit this again.

This change also simplifies the basket view logic and allows a form to
be removed.
Test basket's strategy class is correctly exercised by form

This shows the problem with forms knowing too much of the details of
collaborators. This is a design smell and will be looked at before
things get too stinky.
Validate that basket additions have the same currency as the basket

And this is the outer-most frame of the Yak-shave: preventing the many
errors messages I get from the public sandbox site where people try to
add products of multiple currencies to their basket.

It was quite a journey...
Ensure errors messages are stripped of *s

Not sure why but Django adds a "*" to non-field errors. We get rid of
them as they make our flash error message look weird.
Added ShippingMethodView.is_valid_shipping_method(..)
Raise exception if more than user share email and password

We need to handle a race condition where when a user quickly registers
twice. The RegisterUserMixin already deals with it, but expects a
MultipleObjectsReturned exception. This is now correctly raised.

Fixes #1313
Rename Emailbackend to EmailBackend

The non-camelcased class has bothered me for a long time.
We can remove the deprecated spelling for version 1.0 :)
Management command to find duplicate email addresses

Oscar currently treats the local part of an email address in a
case-sensitive way. That's standards compliant, but the majority of
users is not aware of it and most SMTP server setups ignore casing.

In preparation for switching to a case-insensitive handling of email
addresses, this commit adds a management command to find duplicate email
addressses. Casing is ignored.

Related to #1179.
Disable instead of delete sers with duplicate email addresses

If an external system introduced duplicates, we really shouldn't just
blindly delete the users. This change logs the event and instead
disables them.
Some more redirect() instead of HttpResponseRedirect(reverse())

The file raised a PEP8 line length warning, so I did a bit of
refactoring along the way.
De-emphasize editing address etc. on order preview page

The page should have a clear call to action, which is clicking the
"Place order" button. Any other flow should be more subtle, to reduce
confusion and make it immediately obvious what the next step is.
Allow products with a price of zero

Oscar now supports setting a price of zero for products.

Please note that currently a price of zero has no other special-casing
apart in a template. Notably, setting a currency is still required and
you can't add products to a basket of a different currency. This can
be improved if needed.

In the templates, the product price is displayed as "Free" instead
of zero (and whatever currency).

Writing an (initially failing) test exposed slightly incorrect handling
of the passed price in the stockrecord factory, as a price of zero
would always be replaced by the default price.

Fixes #1347.
Merge pull request #1346 from dimka665/add_is_valid_shipping_method_to_shippingmethodview

Added ShippingMethodView.is_valid_shipping_method(..)