Adjustment refactoring

/cc @BDQ, @jhawthorn, @gmacdougall, @cbrunsdon, et. al.

Some background on this PR can be found in [Sean's post to spree-user](https://groups.google.com/forum/#!searchin/spree-user/Promotions/spree-user/DaMRgT7JnK8/n7VOsB1xfmEJ).

This is my attempt at refactoring the adjustments system within Spree. Here's a couple of key points:

**Originator for adjustments is _gone_**. This caused a lot of confusion and it turns out it's no longer needed. What we have on adjustments instead are the `source` association which is where the adjustment is coming from, and the `adjustable` association which defines which object is being adjusted. Oh, and the `order` association for a reason I'm not quite sure of yet. Please do investigate.

**Tax adjustments are now applied to line items and shipments individually**. Whenever a line item or shipment are updated, it will update the adjustments for those items and then update the totals for the order. This is different to the current system which updates *all* the adjustments and causes a lot of Callback Hell in between the Order model and the Adjustment model.

**Shipments have many adjustments** Previously, shipments had one and only one adjustment which was the shipping cost. Fortunately there was already a `cost` field on the shipment object which is probably a better place to store this "fauxjustment". The adjustments that link to a shipment now will be things such as discounts and credits, i.e. "Free Shipping" promotion.

**Promotion::Actions::CreateAdjustment now applies adjustments to line items rather than an order**. This is so you can clearly see how much of a discount a specific line item has received and then back out only that change if you wish. More on this later.

**Promotion events are gone, gone, gone** These caused waaaay too many headaches trying to figure out what's going on where, and so they're gone. What should be done instead is some smart hooks for specific events, but I've not gotten around to that yet.

**Adjustment eligiblity is set in the one place which needs it**. The only place this was being used was to work out which of a promotion is the better to apply to an order. Since these promotions are now moved to LineItem, this logic for setting eligibility is now moved to the `LineItem` model. I *suspect* we could improve this by moving it into some kind of service class since `LineItem` and `Shipment` instances should calculate the best promotion exactly the same way.

----

Here's the other things that need to be done:

- [x] Correctly pass shipping amount in _google_analytics partial. Currently working on adjustments, but this is no longer the case for these changes.
- [x] Tidy up orders summary page. Show any discounts next to shipments. Show adjustments properly in the final summary. (similar to what's now on the cart)
- [x] Fix issue where cart promotions are ALWAYS eligible. Need check in PromotionHandler::Cart for eligibility, just like what we have in Coupon.
- [x] Apply promotional discounts before tax adjustments. As per [this document](http://www.hmrc.gov.uk/vat/managing/charging/discounts-etc.htm#1) and [this document](http://www.boe.ca.gov/formspubs/pub113/)
- [x] Apply coupon promotions in the background on checkout's payment step. See note in radar/spree@67063a6327434115d0cbede83c4ca990c765eb52.
- [x] Remove event_name field completely
- [x] Make FreeeShipping PromotionActions work.
- [x] Add a `PromotionHandler` for path promotions. Fix related tests in frontend.
- [x] Add a `PromotionHandler` for user sign up promotions, and possibly use it within spree_auth_devise. Fix related tests in frontend (or are they in spree_auth_devise? I can't remember)
- [x] if previous task is done as is written, update custom authentication guide to mention that this event needs to be triggered. (optional)
- [x] Ensure  frontend adjustments are displayed in a sensible manner. Line item costs, followed by line item adjustments (grouped by label), followed by shipments, then shipment adjustments (also grouped by label), then order subtotal (line item + line item adjustments + shipments + shipment adjustments), then order-level adjustments, then order grand total.
- [x] Ensure calculators that can be used for a CreateItemAdjustments action operate on line items, rather than assuming orders.
- [x] Fix frontend tests. There's a couple of stragglers around the place.
- [x] Fix any other broken tests around the place
- [x] Add ability to apply promotion from admin backend
- [x] Migrate old adjustments using originators, to new adjustments that use source
- [x] Migrate old free shipping promotions over to new setup (which uses an Action rather than a Calculator)
- [x] Link orders with promotions so that we can easily track what orders have used which promotions