Refactor stock related service objects to deal with inventory units.

Prior to this change, stock related service objects (coordinator, packer,
prioritizer, package, adjuster) were tightly coupled to orders and line
items, such that they would only create a set of shipments for the set
of line items for an order.

This change makes those objects work with inventory units, which enables
future enhancements that would create shipments for an order that are
not necessarily tied to the initial purchase (e.g. upcoming exchanges
work).
hey @athal7 sorry I can't see where the concept of line item x variant is being addressed (should probably take another look with a better head).

yes please reconsider this approach, I still have a strong feeling that inventory units should be built in Package, definitely not from within Order.

> As far as the inventory units being built here and the state being set later, that allows us to build the necessary inventory units separately from deciding what shipment they go into (and their shipment/stock location is what determines they are on hand or backordered).

Still dont understand the use case. Currenlty you should already be able to build a Package with inventory units with a non persisted shipment, I think you can even set the state to `nil` if you need to, plus you can pass a different variant from the original line item ..