Payment methods should be scoped to available.
Info for products with multiple variants

Setting SKUs for products with multiple variants can be confusing for novice users.

This adds a note on the product form in the place where the SKU field would normally appear. It lists several variant SKUs and invites the user to manage product variants.

Fixes #4897
Bump to Rails 4.1.4
Added without_children = true in taxon autocomplete API Call

We do not need taxon children in autocomplete of product taxons. As we were loading taxon children the response of the API call was slow.

Fixes #4903
Optimize available_countries

Use .sort_by so that we only run .parameterize once per country.

Fixes #4899
Destroy associated adjustments when order is changed to move out of taxable zones.

Fixes #4840
Fixes #4839
Fixes #4916
refactored and fixed tax rate spec

Fixes #4839
Fixes #4840
Fixes #4916
NO TOUCHING in OptionValue#touch_all_variants
optimize touch_all_products performance

use sql update instead of touch each products.

Fixes #4910
Permit first_name and last_name in address attributes

These parameters are aliases for firstname and lastname, and so should be permitted through as well.

This used to work in 2-2-stable, but was broken as of 2-3-stable.
syntactic sugar

so pretty :)
(also generates nicer looking queries)
Merge pull request #4941 from jordan-brough/query-syntactic-sugar

syntactic sugar
Allow setting user_id on order create. Fixes #4922
Need to permit attribute.
Updated bad jsUri link
Merge pull request #4952 from callumacrae/update-jsuri-link

Update jsuri link
Provide gateway profile info for admins. Fixes #4953
Add pry and pry debuggers to common spree dependencies

Including dev environment.

Fixes #4957
Move old ReturnAuthorizations to LegacyReturnAuthorizations

After spending a lot of time working on migrating old return authorization data, it's become clear that doing so would be too error prone without presenting considerable risk of damaging existing data.  And/or forever incumbering future development work on Spree by requiring lots of edge cases and special considerations for legacy data.

Instead of migrating the old data, we instead renamed the existing table "return_authorizations" to "legacy_return_authorizations" and created a [spree_legacy_return_authorizations extension](https://github.com/bonobos/spree_legacy_return_authorizations).  Stores that are migrating from old versions of Spree can include that extension to continue viewing and closing-out their legacy data.  The extension does not allow creating any new legacy data.

Some of the reasons that migrating old data would be dangerous are:

- The old system used adjustments and negative payments to provide refunds, whereas the new system uses the "Refund" model.
- The old system does not provide a direct (i.e. completely reliable) link between negative adjustments and return authorizations.
  - The negative adjustment is linked to the order and has a label of "RMA Credit" but it is not linked to the ReturnAuthorization, and an order can have multiple return authorizations.
- The old system does not provide a direct link between negative payments and return authorizations.  See above bullet, plus in the old system it was very possible to create a negative payment that refunded not only the return authorization but also any other negative adjustment that happened to be pending at the time of the negative payment.
- The old system does not store tax amounts separately.  The new system will have fields dedicated to storing tax refund amounts, and trying to pull the data apart was proving very difficult and error prone, especially when you consider that tax zones may have been added/changed or tax rates changed since the time of the refund.  Leaving tax data blank for legacy data also presents unfortunate edge cases and problems.
- The old system never marked a return authorzation as refunded, and figuring that out (see above items) was error prone.  And leaving the return authorzations as non-refunded in the new system could have dangerous side effects.

All these things together made us think that we and other spree stores with legacy return data would be better served by keeping the old data as it was and providing the above extension to display and finish closing out any in-flight return authorizations.

Notes:

  - This modifies an existing migration. We're assuming no one is running off spree master and that that's OK at this point.
  - We change the "RMA" number prefix to "RA" to prevent conflicts between the old and new tables.

Created by @richardnuno and @jordan-brough

Fixes #4955
Fix typo in Spree::ReturnAuthorization model