Scope eligible when choosing best adjustment

When the order had a better but not eligible adjustment the store would
make all other adjustments not eligible. Instead it should scope
eligible adjustments when figuring out which one should make it to the
order

thanks to @sohara for pointing that out

Fixes #3274
Don't select backend only shipping rates by default

As frontend users shouldn't select shipping rates only meant to be used
via backend. So Estimator by default only marks frontend/generic
shipping rates as selected

Fixes #3287
Don't ignore promo action beyond the first created

Currently Spree allow users to associate multiple actions, e.g
CreateAdjustment, to a promotion however it doesn't allow a promotion to
have multiple adjustments in the same other as the backend UI suggests.

It changes the `order.promotion_credit_exists?` api so that multiple
adjustments can be created for the same promotion even though only one
of them, the one with best amount, will be eligible.

Fixes #3262
Fixes #3276
remove duplicated :payments_attributes in attr_accessible on Order

Fixes #3294
Implemented add, receive, and cancel for Return Authorizations API.

Fixes #3220
[api] reset permalink to nil when ActiveRecord::RecordNotUnique thrown in ProductsController
Add missing translations for option_type_placeholder and variant_placeholder
CreditCard model will now validate that the expiry is not in the past
[api] Correctly parse payment information in Checkouts API

What was happening before was that the parameters were expected to be something like:

     params[:order][:order]

Which you and I both know is just plain wrong.

There were no tests for this particular part of the Checkouts API, so it escaped our notice... until now. There are tests now.

The way I found this was by building spree-marionette and trying to submit payment information to the API, and it would return a $0 amount for the payment... which seemed very wrong.

This is now all fixed.
Return *useful* errors when a payment's source fails validation

No more 'source is invalid' nonsense
'Correctly' define zones association on 'create_shipping_method_zone' migration

Fixes #3307

The issue happened upgrading a 1.3 app to 2.0. What would happen is that this migration expected the table to be called shipping_methods_zones, but a later migration (and a model change in the shipment model) changes this to being spree_shipping_method_zones. This small model code here will redefine the association and appease the migration running script.
Add navigation back to stock locations list from stock movements

Fixes #3281
[api] Do not call set_current_order in CheckoutController

This has been known to clear the current order completely, which is pretty bad.

Fixes #3306
Add changelog entry for set_current_order filter skipping
Fix back to stock locations list entry on en.yml

Fixes #3310
Raise Core::GatewayError when process_payments! is called and there's no pending payments. Can occurr when previous payments have failed.

Fixes #3317
Improve readability of process_payments spec

Related to #3317
Simplify the transition to the order 'complete' state by removing the conditions. The Order.process_payments! method is now responsible for handling the transition correctly, via it's return value when it get's called in the before_transition. Essentially, the filter on definition is now redundant.

has_unprocessed_payments? is no longer required.

Fixes #3317
Raise RecordNotFound in OrderContents#remove

Remove TODO on `remove` method and raises error when the line item can't
be found by variant

Fixes #3316
Show 'No stock locations found' rather than a dodgy looking table when there are no stock locations