I would build 1 fact table and each row in it represents an ingredient like lettuce, hamburger patty, mustard, etc. If I ordered a McChicken and asked for cheese, extra chicken patty, no tomato it would would end up being 4 records/rows in the fact table. 1 for the bread, 1 for the chicken patty, 1 more for the extra chicken patty, and 1 for the cheese.

Another way you could build the fact table is to have 1 row per item ordered and then have a column for each ingredient. How you build the fact table depends on what you're trying to measure. In this table it would be easier to add the price of the McChicken. But in the first table, it could cause confusion because 1 item ends up having multiple rows so what do you do with the price? Split it evenly between the number of rows? Only put it on 1 of the records? Put it on all of them? Any of those options can lead to confusion when querying the table.

Each row would tie to other dimensions like date, store, product, and whatever else is needed. That way you can aggregate results however you need to.