Refactor order amendment capabilities

Refactor delivery amendment functionality in YUM.

We need to integrate with existing ShoppingCart logic so that we can fully recalculate all information about the order prior making any changes.

The basic algorithm should be:
1. Create ShoppingCart from CustomerOrder object
2. Run ShoppingCartCommand that represents the changes to be made.
3. Once all the changes are made, the CallCenter user should click "Amend order" button - this will bring the summary dialog containing brief information about the changes, was/now total, extra pay/refund, coupon codes that are no longer valid.
4. If call centre operative confirms this - the changes are applied (this includes, reserving/voiding reservation, capturing extra payment/ giving refund)
NOTE: we can save ShoppingCart using ShoppingCartState service, so the above steps can persist the changes between actions. Say step once creates ShoppingCart from CustomerOrder and then saves the state returning cart.GUID to YUM. Then when call centre operative makes change to order the shopping cart can be recreated from state and commands run against it.
NOTE (step 3): We can create another ShoppingCart from original order and compare it to ShoppingCart with amendments and produce a OrderAmendmentDTO object with all changes information.

Amend 5th Feb 2015 DP:

I think to do this properly a lot more changes are required, which we will not be able to put in for 2.2.0, namely:

We need to:

1. Capture countryCode and stateCode for billing address with the order as we need to create fake AddressEntity that we can use to calculate taxes for.

2. We need some sort of auditing capability for changes made to the order, there are several options here:
2.1. Option 1: add orderedQuantity to CustomerOrderDet and CustomerOrderDeliveryDet where we can keep original quantity ordered. So for removed line the orderedQuantity will be X and qty will be 0, for added line orderedQuantity = 0 and qty = X, for amended quantity orderedQuantity = X and qty = Y. The drawback is that multiple updates to same line can overwrite the auditing information.
2.2. Option 2: add previousState property to CustomerOrder which will link to CustomerOrder object in its previous state. Every time we make changes we will copy all order lines and link it to current order, then make changes to current order. YUM order viewer will need to be modified to view changes and we also may want to add ccNote property where call centre operatives can add notes as to what had been changed or discussed with customer when this change was made. Full auditing capabilities but more intensive in terms of changes to support this.
2.3. Option 3: just apply changes to current order. No auditing information may create unnecessary disputes when something will go wrong with the order

3. It is possible that amending order is simply adding new coupons to increase discount for user, or give out gifts. For this we need 'Add coupon' functionality.

4. We need a full order editor wizzard that would have a certain flow, for example:
4.1. Create shopping cart from order (this could be driven by the 'edit' button in deliveries).
4.2. Make changes to cart (add/remove quantity, add coupon codes, change order message)
4.3. After all changes we need an update summary screen that would list: change in order total and total discount, list of promotions that are no longer applied to the cart. If the update modifies the order total then we need to check if PG supports capture less/more. The CC operative should be given 2 choices: either use original PG to capture more/less (only available if PG supports this), or manual order amendment PG (this PG has to be added as built in option, this also should be the failsafe option in case capture more/less fails for whatever reason)
4.4. Perform auditing actions as per point #2

In the light of the above stated it is recommended to disable the edit button in 2.2.0 release as it can be harmful to the order data.