Refactor flavor-store relationship handlers

- [ ] 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.

Start by locating the flavor/store relationship handlers and the current DELETE /api/v1/store/{storeID}/flavor/{flavorID} route. Review how relationship IDs and active flavors are represented, then resolve which endpoint approach the project should use. Done means deactivation targets one relationship rather than every matching flavor at a store, with the response and active-flavor endpoint exposing the needed relationship ID.

Written by the indexing model from the issue text.