This also gets initialized with Orders

Updates a comment with the fact that this code is also used with Orders.

At the same time, fix the order delegate. It was not previously being
called, but if it would have been it would have been broken in the case
of usage with an Order
Prevent multiple promotions on the same order

The desired behavior when applying multiple promotions to one order is
for Spree to choose the one that gives the largest discount, but
disable all others. This makes sure that customers cannot combine
multiple discounts.

However, before this change, this was only enforced for promotions of
the same type. I.e. you could only use one line-item-level promo per
order, and one order-level promo per order. But you could combine a
line-item-level promo with an order-level promo and they would both be
applied at the same time, combining the discounts.

With this change, we compare order-level adjustments with the sum of
all line-item adjustments per promotion. Then, we pick the best
promotion and disable all others.

cc/ @huoxito -- I think you are familiar with this code.
cc/ @gmacdougall, @cbrunsdon, as we discussed on IRC
cc/ @athal7 who paired with me on this.
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.

I believe this fixes #4675