Changes to products API

[A-Guldborg]

This PR moves MenuItems into their own directories instead of residing amongst the products.

Furthermore, this PR removes the ChangedProductResponse and replaces this with the ProductResponse. The ChangedProductResponse was used as the return type for products that was added or updated. Instead of having multiple DTOs which would each have to be updated whenever a change was made to the general entity, we now only have one.
The previous implementation of ChangedProductResponse did not contain the value IsPerk nor the Id. This meant that adding a product in shifty would not be able to show the new item's ID (nor conduct further changes) without reloading the whole table of products (i.e. a get request to the /products/all endpoint).
If there was any particular reason to keep these divided, please let me know @HubertWojcik10 :-)

[ghost]

👇 Click on the image for a new way to code review

Legend

[jonasanker]

I'm okay with this PR.

@A-Guldborg I'm always discussing with myself whether it should be the controller layer or the service/repository layer which should be responsible for mapping the object. In API v2, I have generally avoided having a mapper method on the controller layer but I'm unsure whether this should be enforced, thus you get the approval with suggestions :)

[A-Guldborg]

@jonasanker as discussed, I have moved the mapper to the product layer. Please be vigilant when reviewing these extra changes; I do not have the knowledge to be 100% sure that this does not break anything in the purchase flow (using ProductResponse in the PurchaseController rather than the actual Product entity in CheckUserIsAllowedToPurchaseProduct and InitiatePaymentAsync)

[sonarqubecloud]

Quality Gate failed

Failed conditions
73.2% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud