Calculate Order#uncaptured amount on payments on the fly.
Fixes #4831
Fixes #4834
Fixes #4747
Add instructions for contributing to Bonobos fork
Update orders.promo_total in OrderUpdater

NOTE: Cherry-picked from this spree pull request until it gets officially resolved: https://github.com/spree/spree/pull/4607

orders.promo_total field wasn't getting updated in certain cases, like when you add the promo first and then a line item afterward.
the *adjustment* got updated and the correct number was displayed in the cart, but the orders.promo_total value was incorrect.
Ensure correct payment amounts

When paying with only one payment method, ensure that the amount charged equals the amount due.
Pass in order params on order creation so they can be overridden
Use an InMemoryStore to access certain Spree preferences.
add "expected_total" param to checkouts controller

for https://trello.com/c/c0m8hq7y/163-fix-hack-for-forcing-correct-payment-amount-at-checkout

allow the frontend to tell the backend how much it expects to be charged before charging.
if the amount doesn't match then return a 400 with a specific error message.
Associate a user’s shipping and billing addresses with their order when checking out
Add button on admin users edit page to allow admins to quickly associate users and user addresses with new orders
Add deletion protection for promotion actions

When promotion actions get destroyed, all of their completed adjustments
then have a reference to a non-existent source, which causes data issues
when trying to understand what promotion an adjustment was for.

Since promotion actions get destroyed when a promotion changes how it is
applied, which can happen somewhat frequently, adding a paranoia around
it will allow a paper trail back to the original promotion.
Re-choose best available promotion when an order changes

Before this change, we could end up with multiple eligible promotions on
the same order. This happened because changing the order (for example,
by adding line items) rechecked the eligibility of promotions,
potentially making multiple ones eligible, but forgot to re-choose the
one best promotion.

This change adds a call to the logic that chooses the best promotion any
time the ```OrderUpdater``` recalculates adjustments.

Adds test to ensure we do not apply multiple line item promotions

Spec and style improvements

Runs two specs twice with different ordering to ensure the order in
which promos are applied doesn't matter. Also cleans up some style
issues and removes an unnecessary stub.

Add specs for taxable items + promos

Correctly limit a promotion to its maximum amount

You should never be able to reduce the price of an adjustable to less
than zero. Thus, we have to guard against a promo applying a discount
larger than the pre-promo amount.

However, as we also do recalculations, we cannot just use the
post-adjustment amount as a limit here. We have to use the
pre-adjustment amount -- i.e. pre-tax, pre-promotions. That is correct
because a) tax gets calculated on the post-promotion amount and b) there
can only be one active promo per line item.

fix for line_item amount instead of price with associated spec

Conflicts:
	core/spec/models/spree/promotion_handler/coupon_spec.rb

CreateItemAdjustments handles only LineItems

Fixes #4675
Fixes #4775
Fixes #4799
Fixes issue that caused admin users to get unassociated from an order if a user_id parameter was not provided.

With these changes, when a user_id is provided it will either associate the provided user_id to an order if the value is not nil, or disassociate the admin user from the order if the value is nil. When a user_id is not provided, the order will stay associated with the admin user.
Remove rabl version dependency so we can use our fork of rabl in spree-backend to enable recursive rabl caching.
Revert "Ensure correct payment amounts"

This reverts commit d8e83d367f105bf61387d869b47152606b655374.