Refactor inventory-contents-changing code into concern

[armahillo]

Michael has asked this issue be re-scoped to be on doing it as a concern instead.

Regarding methods like adjust, I'd like to eventually refactor them to look more like what I did for update_distribution with a more general process of (backing out the previous donation/distribution/etc, updating/correcting it, then putting it back in) with that process being wrapped in it's own transaction. I think doing so will 1) make our lives easier, 2) unify the app code significantly and 3) make updating logic a lot safer.

Formerly

Currently:
   When distributing or adjusting a storage location inventory, if it hits zero, the item is deleted completely. This creates additional checks that are necessary when doing reclaim! or other re-adjustements

Change:
  Allow the Inventory Item to persist in the association, but at zero quantity. 

**Bonus:**
  Refactor the I/O methods (reclaim/distribute/adjust) so that the adding/deleting to a storage location is independent of what the purpose is (there's some fancy logic with inventory items / line items). Could either be added directly to StorageLocation or maybe to Itemizable instead. 

(Tagging @mdworken , per his request)*```

[mdworken]

@armahillo I've been been thinking that, longer term, we should pull out all of the logic for changing quantities in the storage location into it's own concern.

Regarding methods like adjust, I'd like to eventually refactor them to look more like what I did for update_distribution with a more general process of (backing out the previous donation/distribution/etc, updating/correcting it, then putting it back in) with that process being wrapped in it's own transaction. I think doing so will 1) make our lives easier, 2) unify the app code significantly and 3) make updating logic a lot safer.

[armahillo]

@mdworken That sounds like a great idea! I agree there's definitely a lot of replication across those various number-fudging methods.