Keep it simple!
Modeling is a skill. It's about observing and filtering. Even in a relatively simple business like a Take-away there is a lot of noise and if you manage to filter the noise and keep the essence your entity model will become both robust and flexible. First focus on the absolute minimum. Let me try to show you how this could work in your case.
The filtering begins with finding the "ubiquitous" language (Evans, Domain Driven Design): the "things" the business talks about and that are candidates to become entities in the model.
You talk about meals, types, values, prices, discounts, options, products. What are candidate entities?
One important step to take is to find the real, tangible "things". Customers don't eat options. They eat meals, or products. Nor do they eat prices.
"Option" is an interesting word. It is a covert verb. It's an act of opting for some "thing". It's a common design flaw in modeling to turn actions into entities, while they should become methods working on entities. Finding these disguised verbs is very very important. Without diving too deep into this issue I can say that having actions as entities make it hard to assign the right responsibilities to classes.
Likewise, prices (values) and types are no tangible things. They are attributes of things. Turning attributes into entities is a less obvious error, but it happens. I think the model you show as example contains both of the above flaws.
So far, in fact, the only real "thing" that emerges is a Product. The rest is either action or attribute. A Product can either be a meal, or a component of a meal. So these products come in combinations, or aggregates, which can be modeled by a hierarchy.
So here's the core of your "flexible schema to store Products":
You can store all possible combinations of products in one database table. No need to store options separately. Options are products as well. It's an act of combining to design the options in a hierarchy of products.
A concrete part of the hierarchy, the rice meals, could look like this:
The business does the combining, which is designing the hierarchy. The customer does the picking of options. Here business rules come into play. Let's say one rule is that the owner can combine any products, another rule is the customer can only combine end points (the smaller gray rectangles). The parent product could contain a property telling how many of its children can be chosen.
There may be a way to build these rules into the model, but coded rules are far more easy to modify than a model.. Let the model just be a dumb bag of data.
Now the part
I also need to work out how to store what has actually been selected by the user.
When a customer picks options he is making a classical order with order lines. That would make for a model like
Well, this is getting a long answer. A short word on the discounts. It depends a bit on how you want to calculate them. A simple way is a product property that's simply a multiplication factor to apply to the prices of each child product when more than 1 are selected.
