fix Order#reload method signature

ActiveRecord::Base#reload accepts an `options` argument: https://github.com/rails/rails/blob/v4.1.4/activerecord/lib/active_record/persistence.rb#L386
This code was failing for me:

    >> Spree::Order.first.with_lock { }
    ArgumentError: wrong number of arguments (1 for 0)
    from /Users/jordan/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/bundler/gems/spree-287d40eaf236/core/app/models/spree/order.rb:592:in `reload'
add spree.t with translations instead of t

remove spree.t with must_match_order_currency in ensure_proper_currency method
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
Fix datepicker dropdown arrow style

Fixes #4936
Add small padding to top navigation icons

Fixes #4936
Allow token-based payment sources in Payment::Processing

Related to #4598 and ZD#4573
Fix copy/paste mistake.
Merge pull request #4923 from jordan-brough/fix-order-reload

fix Order#reload method signature
Merge pull request #4912 from vinsol/spree_t

add spree.t with translations instead of t
Fix line item proper currency check