Using more objects in memory during checkout

I've been trying to address some points we always consider when thinking of how to resolve / improve spree performance. Working with objects in memory, doing less `object.reload` and saying good bye to famous `order.update!`.

I started by trying to reduce db queries / ar object loads when adding items to cart (`order.contents.add`), could go as far as running about half less db queries, see https://gist.github.com/huoxito/3d8bcf0d8fa24f54f429, and I've been trying to somehow benchmark this but I'm not really sure how to do it best yet.

These are some from a simple `Benchmark.measure` script https://gist.github.com/huoxito/2e0bc0b97420eb032329. The difference is not much at all really from a simple default spree install (with sample data only). But I'm curious to see how this would go with some more real world store scenario.

Also started looking at the transition from address => delivery and made some changes on the Stock::Estimator to reduce the number of hits on db as well.

I couldn't make all specs pass yet mostly because I'd need more time to catch where is it exactly we're missing fresh data and using the out of date objects from the database (there are some NOTEs on the code though that should help narrow down the hot spots). 

Overall I feel like the end result here is going to be more code and possibly more complex code but I can't really see how else we can achieve better performance. Personally every time I've done something like `order.reload` is because I had lost track of the method calls and just reloading the object, or everything inside spree, would be the easiest way to go.

will still try to make those specs green but I wanted to share this with everyone to get feedback since I've spent already quite a decent amount of time on it.

// @BDQ @JDutil 
I can't agree with you here. Both reasoning you listed above applies to the other approach as well.

You'd have to pass the order the same way to an object, `object.order = order`, isn't that an additional parameter (or call it _action_ you will always need to take in order to get an accurate result)? I prefer `object.update!(order)` instead because it's a bit more clear why I'm passing that order (because that `update!` method needs it). Second assigning the order to the object like that also _Opens up the potential for bugs when the order passed in does not correctly match adjustable._ because the very same way we're passing an object to the other.

Anyway this is a tiny detail and honestly I'm not willing go through the refactoring again and build runs right now because I don't see the benefits would be worth it. I'm sure if we can change that on the way if it's needed. btw what if the `adjustable` thing is not tied to an order? Is that contract worth it to kill a parameter?