Follow up on adjustment refactoring latest changes

I'm creating this just as a way to tell you where I'm going with adjustments refactoring so that once you get back you can have a good idea of what I've done. Later on I might create separate PRs for each change as we all agree which ones are good. And in case this all sounds good I can clear the not appreciated merge commits and do some more squash so that it can be merged the spree way.

btw this already includes #2, #3, #4, #5

Let me know your thoughts once you have a chance :) I should keep adding more commits over the week right now I'm looking at how the store behaves going through frontend checkout.

cc @radar 

*updated now that the week is over to give you a summary of the changes*

* Set up two PromotionAction classes or to create adjustment over orders and another one to create adjustment over line items.

I've added specs to cover both scenarios but sure we will need way more. Also most of the current calculators api expect to receive only an order object to compute values so I guess we need to create calculators for items (shipments, line items) objects.

* Removed order.update! from LineItem callbacks.

Please take a look at the OrderContents class. All changes in order line items should go through that class now I think. e.g. adding items to cart, updating quantity, updating more than one line item at once, removing line items. I also believe that OrderContents `add` method is a good place to activate promotions targeted at items change on the order.

* Introduce a PromotionItemHandler class to activate promotion at line items or promotions triggered when an item is added to cart.

* Shipment `cost` atttribute is now save before order transitions to payment (after customer choose a shipping rate for each shipment).

The way spree saved shipping costs was a bit confusing imo. It did that in a callback where it would keep checking if there was a selected shipping rate. When it found one it would create an adjustment while the `cost` table column was not actually used anywhere as far as I could see.

Now instead of creating that adjustment it grabs the selected shipping rate amount, copy over to the cost table column and persist that in that column. Shipments can still have other adjustments though. e.g. promotion discounts or taxes. Please see Order `set_shipments_cost` that's where it persists shipments cost and then update the order totals (rather than doing it every time a shipment is save).

I think those are the most important changes I can remember right now. The commit logs should tell you more. I hope it all makes sense. I'm really excited about how it's going so far.

This is how the order summary looks like now (I'm aware order total is still not accurate):

![screen shot 2013-08-25 at 17 53 19](https://f.cloud.github.com/assets/245662/1023063/844e65da-0dc8-11e3-83cf-90be9a9031e6.png)


Some problems still no solved and I'm not sure how we can solve it yet:

* When and where should line items taxes be created? Is creating both line items and shipments taxes at once a good idea? (that what happens right now)

* We need a way to differentiate promo codes promotions, add to cart promotions sign up etc .. I guess we all agree adding hooks to specifics parts of the code is the way to go but I think we still need a way to only grab those specific kinds of promotion in each place. (something like the `event_name` column).

* Figure out where and how to set adjustments eligibility (that's something I haven't touched yet)

I guess there's a ton of info here already. Let me know if any of it makes sense and any questions you have about it. cheers!