This PR triggered a discussion about how we handle lot numbers in general in the application. I won't handle the following in this PR since it'll require a proper design/discovery, but some ideas for future improvements include:

• bonus: consider renaming the current InventoryItem entity to ProductLot and then creating a separate InventoryItem entity that has a Location facility field so that it represents a product lot at some facility.
• add getOrCreateProductLot(String lotNumber, LocalDate expirationDate) and getProductLot(String lotNumber) methods somewhere that standardizes how we handle lots in our system
  • should blank string lots be allowed or should we trim input? (probably trim but would need a data migration...)
  • should we treat "" as the null lot? (probably but again we'd need a data migration, which might be more trouble than is worth)
• standardizing data-binding for lots in imports. Use the above getOrCreateProductLot method!
• standardizing data-binding for lots in APIs. Use the above getOrCreateProductLot method!
  • I'd be great if we could do this automatically: create a value converter for ProductLot/InventoryItem that if given a String lotNumber, LocalDate expirationDate combo will resolve the class by calling getOrCreateProductLot
• create a lot picker component on the frontend that we can use anywhere that a lot can be selected. It selects from a dropdown list of existing lots on the product and there's a button to add a new lot.
  • This would simplify our APIs that use lots since they can always expect that the given lot exists. Importers would be the only ones that still need to support getOrCreateProductLot (at least until we refactor those flows. Maybe we could have a middle step that notifies the user what lots are going to be created so they can make a more informed decision about it)