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
Payments with a cvv_response_message are not necessarily risky.
Remove defunkt spec that's no longer true.
Use permitted_option_value_attributes instead of permitted_option_type_attributes

Fixes #4772
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.

Fixes #4806

Conflicts:
	core/app/models/spree/promotion_action.rb
[api] Ensure order ids are ordered in orders_controller_spec
Include sample in top level rake test and test_app

Fixes #4808
Fixes an issue where entering 30.49 would preauthorize 3049$.

Fixed by using both the dot (.) and the custom decimal separator for amount parsing.

Fixes #4259
Pagination and search in property list

Fixes #4369

Conflicts:
	core/app/models/spree/app_configuration.rb
make sure we fail fast and exit when a spec fails

Conflicts:
	Rakefile
Javascript fixes for IE8.
Update backends adjustments controller to fix order.update! call.
Fixes receiving RMA's when inventory tracking is turned off.
Fix broken spec.
Typo fix

Fixes #4814
Dont destroy all order payments in api/checkouts

Can't see why we would do that, no spec coverage or git history to
explain that behaviour either
Improving performance of migration add_line_item_id_to_spree_inventory_units

I noticed when I ran these commands on the console that the line

    shipments = Spree::Shipment.includes(:inventory_units, :order)

would load a tremendous amount of stuff from the database, negating the performance savings by the `find_each` method. This may even be a Rails bug. Putting the `includes` and the `find_each` into the same line fixed performance issues immediately.
Calculate Order#uncaptured amount on payments on the fly.
Fixes #4831
Fixes #4834
Fixes #4747
Adding data-hooks to search results header

Our app modifies the look of the page when no results are found, and in order to do that we have to override this entire partial. I'm thinking that adding some data-hooks might make it easier for folks like us to modify just a part of the partial if needed.

Fixes #4820
Fixes Zone #contains? n+1 query performance.

Fixes #4832