Add a call to advance an order as far as it can go

This is related to #3336, as the backend has been changed to add line
items through the API, but the desired functionality is to continue the
order as far through the checkout process as possible after items have
been added.

Extracting this 'advance' into its own API call will let us remove the
while @order.next; on in spree/admin/orders_controller#update on the
backend.

Explicitly advance an order on variant changes

Previously, correct behavior relied on GET orders/edit advancing an
order as far ahead as possible. This explicitly moves the order as far
ahead as possible rather than relying on the behavior of the GET edit to do
so

Related to #3336

Fixes #3662
Do not call refresh_shipment_rates on an order if it is complete

Fixes #3648
Added missing internationalization for table headers (using same table headers as in shared/_order_details)

Fixes #3656
Use jquery.payment for frontend + backend checkout form
No longer create duplicate roles within Spree

Fixes #3557
[backend] use 'complete?' not 'completed?' in orders_controller_spec
Fix issue where refresh_rates for a shipment wasn't being called in VERY specific circumstances

The order_details_spec in backend was failing because of the absence of this code.
Update columns using update_column, rather than update_attribute which now calls callbacks.

Calling the callbacks causes the shipments to be reset to pending because, for some reason I did not investigate, the inventory units are set to 'backordered'. Do not want.
[backend] Correct orders_controller_spec stubbing
Fill in card expiry in checkout_spec
Allow 'expiry' to be passed through as a source attribute
[frontend] Fix translation for 'Expiration' in checkout/payment/_gateway
Adding data-hook for line_item_description

Same change as in https://github.com/spree/spree/commit/a4de83cd2376ba9666ec9fc63f68f7fadf236f73 on the 1-3-stable branch, but for the 2-0-stable branch.

Fixes #3667
Pass updaated order object to `adjustment.update!`

Make things easier to recalculate promo adjustments on updated order
totals without relying on `inverse_of: :source` option (a shipment can
also be an adjustment source). Introduce a `update_shipping_adjustments`
so that shipping adjustments are still recalculated properly as they
need to be calculated over a shipment object instead of an order.

Fixes #3549
Pass updated order object to `adjustment.update!`

So that the adjustment can be recalculated over updated order totals. It
also introduces an `update_shipping_adjustments` method because we
shipping adjustments will need a shipment object and in that scenario we
don't need to pass the order

Fixes #3492
[backend] Order no longer receives next calls in OrdersController#edit
fix conflicts in order_updater_spec
Don't load all promos to apply a coupon code

Fixes #3509
[api] Implement pagination for taxons#index route

Fixes #3501
Adding missing singular/plural names for models in core

[Fixes #3674]