Test for data-loading-text directly

This reduces API complexity at the cost of removing the possibility to get
the pure bootstrap behaviour that doesn't check for invalid fields. I
cannot imagine a use case where the pure bootstrap behaviour is better, so
I took the opportunity to reduce complexity.
Update and minimize jquery-ui

So that it doesn't unnecessarily conflict with bootstrap's $.fn.button().

This is a jQuery UI custom download with just the components we currently
use:

* Version: 1.11.2
* Interactions
  * Sortable
* Theme: Cupertino

(Other dependencies get selected automatically.)
Remove jquery copy in jquery-ui

We get our jQuery elsewhere.
Allow easy overriding of jquery-ui

In case an oscar implementation needs more components than standard oscar
Copy disable-on-submit functionality over from frontend to dashboard
disable-on-submit all submit buttons: frontend
disable-on-submit all submit buttons: dashboard
disable-on-submit all submit buttons: sandbox
disable-on-submit all submit buttons: demo site
Improve docs for Application.permissions_map

This just led to confusion, so I decided to improve the docs a bit.

We really should be using Pytohn sets instead of lists for this.
Merge pull request #1554 from machtfit/disable-button-on-submit

Disable button on submit
Recompile CSS files

See https://github.com/django-oscar/django-oscar/commit/8e2b12647ba78a749b73c804d5d7c9df52d81afa#commitcomment-8502671
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.