3652 #1: kits to items

[dorner]

This PR is the first step in the kit redesign. It moves line items from kits to the kits' item. This will set us up to make items the only table that has line items, which will make the next step (turning kit into a subclass of item) easier.

• Add Itemizable to the Item class. This will only be used for items that represent a kit.
• Rename the current line_items to used_line_items association inside Item - we need some way of differentiating between line items that belong to the item (as part of a kit) and line items that the item is part of (e.g. distributions, donations). There are very few uses of item.line_items so it's easier to switch the name of this association.
• On create, attach the line items to the kit's item, not the kit. There is no way to edit a kit's line items once created.
• Move the validation "kits must have at least one line item" to the creation service class. We can't add this to Item because there are plenty of items with no line items. Eventually we'll be able to add this back once Kit is a subclass of Item since we could look at the type.
• Update all query code to look at items' line items, not kits'.
• Add a migration to move all existing kits' line items to their items.

Note that this PR does not include a feature flag. Although this is a somewhat risky change, it is not difficult to switch back if we have to:

• Every line item that belongs to an Item can only have originally been on a kit;
• For every line item that belongs to an Item, that item will have a kit_id.

Using this, we can easily set the type and ID back to the kit if we need to roll back. Trying to feature flag this would be difficult because we are talking about changing the source of an association. Simply changing the flag won't help - we'd need a redeploy anyway if something is going wrong. If anything, it's more risky to feature flag this because the flag would have to line up with the data in the database. Anything out of sync would break things worse than the rollback.