Remove commented code
WIP Refactor checkout

This decouples the checkout flow from the individual checkout views.

There are now three checkout view mixins:

  1. checkout.session.CheckoutSessionMixin puts relevant checkout info in
     the template context. Pre and skip condition code has been removed.
  2. checkout.mixins.OrderPlacementMixin as before has the meat of making
     an order from a basket and handling payment. After placing the order
     control is returned to CheckoutFlow.
  3. checkout.flow.CheckoutFlow is new and manages the checkout flow.

CheckoutFlow provides checkout(), which uses the checkout session data to
determine the next step in the checkout, and redirects there. If all
steps are complete, it lets OrderPlacementMixin handle the basket to make
an order.

If a redirect payment method is used, the payment result view can call
checkout_failed() or checkout_successful() to return flow control to
CheckoutFlow. checkout_failed() will show the preview page again, and
checkout_successful() will redirect to the thank-you page. This allows
customizing this part of the flow independently of the payment
implementation.

The individual checkout views were stripped of pre and skip conditions and
other checkout flow code. The all use the CheckoutFlow mixin instead of the
CheckoutSessionMixin or the OrderPlacementMixin.
Fix oversight
Fix deprecation warning

Without this, I get

DeprecationWarning: BaseException.message has been deprecated as of Python 2.6

when running oscar_fork_app with a non-existing destination folder.
Add missing newlines

PEP8 knows that real files have newlines at the end.
Don't create CommunicationEvent here

The only caller does that already.

Fixes #1437.
Rework order emails.

This allows implementors to send order-related emails for example to the
partner by overriding handle_successful_order and calling
send_order_message(order, 'ORDER_PLACED_PARTNER', partner.user).
Clarify which payment events the method permits.
Allow access to the created events for custom order processing

One might extend the events with additional fields and fill these in a
customized EventHandler.
Allow specifying other model attributes when creating custom benefits or conditions

For example, a custom benefit class might want to make use of
get_applicable_lines, which needs a range on the benefit.
Don't break sentence spelling/grammar in German.
Make Benefit classes more reusable

Custom Benefit classes can now derive from PercentageDiscountBenefit or
AbsoluteDiscountBenefit and dynamically pass a discount value resp.
percentage as well as a maximum total discount amount.
The code handles the no applicable lines case well without this statement

At also allows me to remove the complexity exemption.
applies_to_tax_exclusive_prices has been removed in f03a7e8
Remove conditions and benefits

Remove the conditions Coverage, Value and Count and the benefits
AbsoluteDiscount, FixedPrice and Multibuy. Add NoneCondition for offers that
apply to all baskets.

Reason is that the correct semantics are unclear and we don't need them now
and I don't want to spend time fixing the tests for them. I'll refactor
offers without them.

Example for unclear semantics:
https://groups.google.com/forum/#!topic/django-oscar/vceEpy889O4
https://groups.google.com/forum/#!topic/django-oscar/XMuhEBLbv-U
Don't create objects in the database unless necessary
Refactor offers

To track benefit application on a separate data structure instead of the
basket line. This uncouples the database-bound basket from the offer
calculations.
Support multiple benefits per line
Apply offers in order of descending priority

This already worked only within site offers by way of default model
ordering. Site offers are probably the most common offers, however the
ordering of all offers has to be controlled by the applicator.
Allow access to all non-voucher offers in offers dashboard