Selected Answer
The beauty of Excel is in that it inserts no sharp divide betweeen data and their presentation, as SQL or Access do. From a properly designed database it would be absolutley no problem to extract all allergenic or non-allergenic ingredients, all products that contain a particular ingredient or those, intended for the same purpose but not containing a particular one. Your database has none of these capabilities. It highlights certain ingredients - the job of a presentation.
You find yourself in the situation of wanting to create a presentation from a presentation. That's like making a river flow uphill. It can be done, with great effort, over a small stretch, for a limited time - but for which benefit?
Your database has already lost many, if not most, of the capabilities it should have by having allowed the design of a presentation to creep into this one field. To undo the damage you would now have to read each character in the field, plus its font properties, instead of reading the entire field, in fact you could read the entire column in the same time you now get a single character. Other than the sheer cost of getting such a program the effort isn't prohibitive in terms of time it takes to display a single item, probably less than a tenth of a second for each call. But the cost you should consider is the uselessness to which you condemn your database in regard to other tasks that should come natural to it. Here a list that must surely be central to your business is degraded to fit a single purpose which, in final analysis, is merely a convenience.
Obviously, a proper db would list each ingredient in its own column, perhaps with an "x" or Yes/No or even the quantity of it in the product (perhaps in the future), and separate columns for each ingredient's properties, such as allergenic: Yes/No. Such a db would be much easier to maintain than what you have and what now passes for your "database" would be easy to produce from it, as would be the item definition you are now chewing on.
As an interim or make-shift solution you do need to get rid of your bold characters. You can keep them as a means of presentation but not to define data. Your list of ingredients must be neatly comma-separated and the allergenic property might be indicated by additional characters, e.g. Salt (A), Pepper (A), Carotin, Spinach (A). Such a field would be machine-readable, thereby restoring most of a db's properties and capabilities to your data collection. It would be slow to work with and hard to maintain free of errors - for example, attention must be paid to place commas correctly, a task that doesn't exist in a real db and therefore can't cause entry mistakes there - but it would give you the capability to split the unwieldy Ingredients field whichever way you want, including make separate columns of it in the future.