This is more of a OOP textbook solution.

Each item would have a list of components like Equipable, Edible, Sellable, Drinkable, etc. An item can have one or none of each component (for example, a helmet made of chocolate would be both Equipable and Edible, and when it is not a plot-critical quest item also Sellable). When the user right-clicks on an item, the components of the item are iterated and context-menu entries are added for each component which exists. When the user selects one of these entries, the component which added that entry processes the option.

This is more of a OOP-by-the-book solution which is based on inheritance and polymorphism.

Each object of class Item would have a list of components like Equipable, Edible, Sellable, Drinkable, etc. An item can have one or none of each component (for example, a helmet made of chocolate would be both Equipable and Edible, and when it is not a plot-critical quest item also Sellable). The programming logic which is specific to the component is implemented in that component. When the user right-clicks on an item, the components of the item are iterated and context-menu entries are added for each component which exists. When the user selects one of these entries, the component which added that entry processes the option.

The ancient obsolete old-school method. All items are dumb plain-old-data types without any methods but lots of public attributes which represent all properties an item could have, including some boolean flags like isEdible, isEquipable etc. which determine what context menu entries are available for it (maybe you could also do without these flags when you can derive it from the values of other attributes). Have some methods like Eat, Equip etc. in your player class which takes an item and which has all the logic to process it according to the attribute values.

Each item would have a list of components like Equipable, Edible, Sellable, Drinkable, etc. An item can have one or none of each component (for example, a helmet made of chocolate would be both Equipable and Edible, and when it is not a plot-critical quest item also Sellable). When the user right-clicks on an item, the components of the item are iterated and context-menu entries are added for each component which exist. When the user selects one of these entries, the component which added that entry processes the option.

The ancient obsolete old-school method. 

All items are dumb plain-old-data types without any methods but lots of public attributes which represent all properties an item could have, including some boolean flags like isEdible, isEquipable etc. which determine what context menu entries are available for it (maybe you could also do without these flags when you can derive it from the values of other attributes). Have some methods like Eat, Equip etc. in your player class which takes an item and which has all the logic to process it according to the attribute values.

This is more of a OOP textbook solution.

This pattern uses composition instead of inheritance and is closer to how the rest of Unity works. Depending on how you structure your game it might be possible/beneficial to use the Unity component system for this... or not, your mileage may vary.

Each item would have a list of components like Equipable, Edible, Sellable, Drinkable, etc. An item can have one or none of each component (for example, a helmet made of chocolate would be both Equipable and Edible, and when it is not a plot-critical quest item also Sellable). When the user right-clicks on an item, the components of the item are iterated and context-menu entries are added for each component which exists. When the user selects one of these entries, the component which added that entry processes the option.

As with everything in software development, there is no ideal solution. Only the solution which is ideal for you and your project. Here are some you could use.

Option 1: The procedural model

The ancient obsolete old-school method. All items are dumb plain-old-data types without any methods but lots of public attributes which represent all properties an item could have, including some boolean flags like isEdible, isEquipable etc. which determine what context menu entries are available for it (maybe you could also do without these flags when you can derive it from the values of other attributes). Have some methods like Eat, Equip etc. in your player class which takes an item and which has all the logic to process it according to the attribute values.

Option 2: The object-oriented model

Have a base-class Item from which other items like EdibleItem, EquipableItem etc. inherit. The base class should have a public method GetContextMenuEntriesForBank, GetContextMenuEntriesForFloor etc. which return a list of ContextMenuEntry. Each inheriting class would override these methods to return the context menu entries which are appropriate for this item type. It could also call the same method of the base class to get some default entries which are applicable for any item type. The ContextMenuEntry would be a class with a method Perform which then calls the relevant method from the Item which created it (you could use a delegate for this).

Regarding your problems with implementing this pattern when reading data from the XML file: First examine the XML node for each item to determine the type of item, then use specialized code for each type to create an instance of the appropriate sub-class.

Option 3: The component-based model

Each item would have components like Equipable, Edible, Sellable, Drinkable, etc. An item can have one or none of each component (for example, a helmet made of chocolate would be both Equipable and Edible, and when it is not a plot-critical quest item also Sellable). When the user right-clicks on an item, the components of the item are iterated and context-menu entries are added for each component which exist. When the user selects one of these entries, the component which added that entry processes the option.

You could represent this in your XML-file by having a sub-note for each component. Example:

   <item>
      <name>Chocolate Helmet</name>
      <sprite>helmet-chocolate.png</sprite>
      <description>Protects you from enemies and from starving</description>
      <edible>
          <taste>sweet</taste>
          <calories>2560</calories>
      </edible>
      <equipable>
          <slot>head</slot>
          <def>20</def>
      </equipable>
      <sellable>
          <value>120</value>
      </sellable>
   </item>

As with everything in software development, there is no ideal solution. Only the solution which is ideal for you and your project. Here are some you could use.

Option 1: The procedural model

The ancient obsolete old-school method. All items are dumb plain-old-data types without any methods but lots of public attributes which represent all properties an item could have, including some boolean flags like isEdible, isEquipable etc. which determine what context menu entries are available for it (maybe you could also do without these flags when you can derive it from the values of other attributes). Have some methods like Eat, Equip etc. in your player class which takes an item and which has all the logic to process it according to the attribute values.

Option 2: The object-oriented model

Have a base-class Item from which other items like EdibleItem, EquipableItem etc. inherit. The base class should have a public method GetContextMenuEntriesForBank, GetContextMenuEntriesForFloor etc. which return a list of ContextMenuEntry. Each inheriting class would override these methods to return the context menu entries which are appropriate for this item type. It could also call the same method of the base class to get some default entries which are applicable for any item type. The ContextMenuEntry would be a class with a method Perform which then calls the relevant method from the Item which created it (you could use a delegate for this).

Regarding your problems with implementing this pattern when reading data from the XML file: First examine the XML node for each item to determine the type of item, then use specialized code for each type to create an instance of the appropriate sub-class.

Option 3: The component-based model

Each item would have a list of components like Equipable, Edible, Sellable, Drinkable, etc. An item can have one or none of each component (for example, a helmet made of chocolate would be both Equipable and Edible, and when it is not a plot-critical quest item also Sellable). When the user right-clicks on an item, the components of the item are iterated and context-menu entries are added for each component which exist. When the user selects one of these entries, the component which added that entry processes the option.

You could represent this in your XML-file by having a sub-node for each component. Example:

   <item>
      <name>Chocolate Helmet</name>
      <sprite>helmet-chocolate.png</sprite>
      <description>Protects you from enemies and from starving</description>
      <edible>
          <taste>sweet</taste>
          <calories>2560</calories>
      </edible>
      <equipable>
          <slot>head</slot>
          <def>20</def>
      </equipable>
      <sellable>
          <value>120</value>
      </sellable>
   </item>