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 rename the existing table "return_authorizations" to "legacy_return_authorizations" and provide 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 legcay 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 present unfortunate edge cases and issues.
- 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 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.