Refactor flavor-store relationship handlers

[jcorry]

• Include the relationship ID in the response to activate the flavor/store
• DELETE becomes /api/v1/flavor-store/{relationshipID}
• A /api/v1/store/{storeID}/flavor endpoint will return active flavors at a store. Each will need to include a flavor_store_id that is the ID of the relationship and the key by flavors will be deactivated at stores.

The alternate approach is to change the delete endpoint to /api/v1/store/{storeID}/positon/{positionID} and just remove whatever flavor is present in the position.

I'm doing this because the way I'm handling the flavor deactivation now /api/v1/store/{storeID}/flavor/{flavorID} is appropriate for deactivating ALL instances of {flavorID} that are active at {storeID}. This isn't awesome though. Imagine that salted caramel is very popular and always present. When the current salted caramel is at 20% full and the adjacent position (mint chocolate chip) runs out, they pull the empty mint chocolate chip and put a new salted caramel in that position. Now there are 2 salted caramels active...one at 20% full, the other at 100% full. When the 20% runs out, a call to DELETE /api/v1/store/1/flavor/14 (where 14 is the ID for salted caramel) will deactivate BOTH salted caramels. That's not what we want.

[jcorry]

@syntacticNaCl and @jmfulgham I'd love your input on how to best structure the API here...