Allow coupons added to order (when not in draft) to apply the corresponding promotion

There are some severe implications connected to this feature request

1. If order were to be refreshed - the price resolver may resolve different price, different promotions can apply, tax rate can change, etc. This will impact the entire order.
2. Applying promotion typically results in price change. Price change calls for adjustment of the tax adjustment
3. Non-draft orders, especially orders in the final state (state_machine) should be considered immutable. If they are not, the list of allowed option should be curated and implemented on per case basis.

I think this issue boils down to an UX issue - order edit form should not expose the coupon code field.

@zaporylie You are completely correct; this is simply a UX/UI issue that could be improved.

Updated issue title and summary in connection with #6 and #7

Here's a patch that changes default field display options.

I don't like this fix, you could still edit a draft order? And the coupon would be applied. Additionally on several projects I need to manually re-apply coupons on placed orders, I then have custom scripts that trigger a slightly modified version of the order refresh that doesn't involve the price recalculation.

@jsacksick I think the points made in the issue summary are correct. Which fix would you find useful here? So maybe we could proceed fixing this. (I also don't like the approaches from patches here)

Yep, no problem around making the coupons field configurable...