Enable default credit card work in storefronts
New paradigm for customer refunds

Initial step in a larger piece of returns & exchanges improvements.

Major

* new "refunded" state for return authorizations
* separation of refunds from payments
  * add a new refund model
  * use "refunds" in place of negative payments
  * stop generating order adjustments when receiving return authorizations
      * we no longer need to create order adjustments in order to provide refunds
* updated admin ui
  * added a "refund" button in the return authorization flow
  * list refunds along with payments
  * add payment identifier column to payments list

Minor

* extra validation on `ReturnAuthorization#force_positive_amount`
* improve some existing specs by using real `ActiveMerchant::Billing::Response` objects instead of doubles

Generated by @jordan-brough & @richardnuno

Fixes #4883

Conflicts:
	core/app/models/spree/return_authorization.rb
	core/spec/models/spree/return_authorization_spec.rb
Take adjustments into consideration when calculating RMA totals

* Added #total_per_item to line_item that calculates total per item including adjustments
* Added new column in the RMA admin screen to display the total per item for a variant
* Updated javascript that suggests the RMA total to use the total per item when calculating

Fixes #4895
Rework ReturnAuthorization-InventoryUnit relationship

* Create a join table: `ReturnAuthorizationInventoryUnit`
  * Allows inventory units to be part of multiple RMAs (e.g., if an initial RMA was cancelled) while still retaining historical data
  * Migrate existing data into the new table
  * Drop the `inventory_units.return_authorization_id` column
* Start using nested attributes for adding/removing InventoryUnits to ReturnAuthorizations
  * Remove the `API::ReturnAuthorizationsController#add` endpoint (use nested attributes instead)
* Pave the way for exchanges with an `exchange_variant_id` field
* Update the admin interface for `Admin::ReturnAuthorizationsController`:
  * No longer group inventory units by variant.  This will be important for allowing per-unit data, such as for exchanges

Created by @richardnuno and @jordan-brough

Fixes #4907

Conflicts:
	api/app/controllers/spree/api/return_authorizations_controller.rb
	core/app/models/spree/return_authorization.rb
	core/spec/models/spree/return_authorization_spec.rb
Rename return_authorization_inventory_units to return_items

Shortening the name of return_authorization_inventory_units since it was becoming a nuisance.
Fixes #4920

Conflicts:
	core/app/models/spree/return_item.rb
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
Add tax related components to return items. Fixes #4964
Always store the pre_tax_amount for the provided item

Allows access to pre_tax_amount regardless of whether the item has included tax or not.

Closes #4945

Conflicts:
	core/spec/models/spree/tax_rate_spec.rb
Introduce refund and return authorization reason.

Fixes #5003

Conflicts:
	backend/app/views/spree/admin/return_authorizations/_form.html.erb
	core/app/models/spree/return_authorization.rb
	core/spec/models/spree/return_authorization_spec.rb
Finish replacing old refund system:

- Stop requiring negative adjustments in order to perform refunds
- Add new admin pages to manage refunds
- Remove Payment#credit! (and associated controller actions) and instead use refund objects that are linked to payments
- Update Payment#cancel so that it no longer falls back to a full refund
- Refactor some code in the Refund model

Fixes #5012

Conflicts:
	api/app/controllers/spree/api/payments_controller.rb
	core/app/models/spree/payment/processing.rb
State machine for return_items.

Fixes #5041
Show flash errors for resource controller html requests

and not for js requests.
When a resource controller failed to create/update there was no indication of what had failed.

Also adds "with_model" gem to allow easier isolated testing of `Spree::Admin::ResourceController`.

Fixes #5011
Added a `ReturnAuthorization.return_item_tax_calculator` class attribute that is set to `Spree::ReturnAuthorizationTaxCalculator` by default.

When `ReturnAuthorization#process_refund` is called, the tax calculator is called with all return items and tax is calculated and stored on each return item and then the refund is performed with the new total.
Taxation is broken out like this to allow easy integration with third-party tax services.

Also:

- Moved some rounding further out since it was causing small but noticeable differences in refund amounts (off by 8 cents sometimes, for example).  And increase precision of some return_items fields along with that.
- Refactored return authorization controller specs so that the spec data is more correct
- Added an additional validation to #process_refund to abort the refund if we know we don't have enough funds to reimburse the customer fully

Closes #5043

Conflicts:
	core/app/models/spree/return_authorization.rb
Add data-hooks to the admin order detail side menu

Fixes #5086
Refactor stock related service objects to deal with inventory units.

Prior to this change, stock related service objects (coordinator, packer,
prioritizer, package, adjuster) were tightly coupled to orders and line
items, such that they would only create a set of shipments for the set
of line items for an order.

This change makes those objects work with inventory units, which enables
future enhancements that would create shipments for an order that are
not necessarily tied to the initial purchase (e.g. upcoming exchanges
work).

Fixes #5042

Conflicts:
	core/CHANGELOG.md
	core/app/models/spree/order.rb
	core/app/models/spree/stock/package.rb
	core/spec/models/spree/order_spec.rb
	core/spec/models/spree/stock/package_spec.rb
Customer returns

Introduces customer returns which represent getting merchandise back from the customer. The presence of a customer return (and it’s associated return items) indicate that a customer has returned something and the store has received it. A customer return also has an associated stock location which indicates where the customer has returned the merchandise.

Customer returns replace the “Receive” button behavior in return authorizations. Receiving an RMA would be achieved by creating a customer return and selecting all the items in an RMA. Given that a customer return is not tied to a particular RMA, it allows a store to accurately represent what is returned. The logic to whether each particular item should be accepted or rejected will be handled in a future PR.

Once the customer return is created, the admin can refund the customer for the customer return’s total amount similar to the refund button in RMA.

Conflicts:
	core/app/models/spree/return_authorization.rb
	core/app/models/spree/return_item.rb
	core/config/locales/en.yml
	core/spec/models/spree/return_authorization_spec.rb
Make sure to associate newly built inventory units to their order
Fixes #5088
Add return item eligibility validator and associated state machine updates. Add a column to persist state transition errors
Fixes #5089

Conflicts:
	core/app/models/spree/return_item.rb
Fix syntax error.
Add postal code validation using the Twitter Cldr gem

Closes #5079

Conflicts:
	core/app/models/spree/address.rb