Click vs click-and-hold. Click performs the "default" action for the item. Attacking for enemies, opening for chests, etc.
Click-and-hold can pop up a radial menu. Player moves slightly toward the option they want and lets go of the mouse to initiate the action.
Optionally, if the user lets go once the menu is open (while the cursor is still in the central "dead zone"), then leave the menu open until the user clicks again.
It's also quite reasonable to use right-click for opening the alternatives menu.
You should also condider a mouse icon that indicates what the default action is and an extra symbol to denote if more options are available, or show the radial menu dimmed out / transparent to indicate that it is available.
This is a less-than-perfect system. You might consider gamepad support and contextual keys. e.g. X is always "attack" if available, "mount" for ridable objects, etc., and then you can pop up a small display for "(X) - Drive" when on such an object.
You can also just allow more keys or key modifiers, as suggested. Supporting more than one is only a problem if you don't tell the user about them in an adequate way. A small introductory/tutorial area that requires the user to use all the extra keys (in a fun, non-hand-holding way) works well. Small reminders or on-screen hints in appropriate places and obstacles that require a certain key use to pass in a natural "makes sense to be there" tutorial area works a lot better than a contrived tutorial location with forced "click X now or you can't do anything" kind of things and is easier to implement anyway.
Each Item Definition, shared by all instances of a particular item (some "unique items" may be the only instance of a particular definition) should contain a list of Actions. Each action should denote using a system-defined enumeration what Interaction Method it uses. This enum should map to a keyboard command list for keyboard input (if supported), gamepad buttons (if supported), and icons (for mouse input) plus string names (localizable, of course).
Each action then has a Response Type, which is what happens when that action is performed. It may make sense for this to be implicit by the interaction method, e.g. "Open" always opens the item's inventory. For maximal flexibility you might wants scripts or other special behavior attached to actions, such that you can have actions like "ring bell" or "kick" that do different things for different object. You could also simplify this by simple having an event sent for a particular interaction method type which can be intercepted by a script or go to a default system.
An item definition should not be allowed to contain multiple actions with the same interaction method. You might also want to have a way of denoting conflicts between interaction methods, especially for gamepad support (e.g. two methods that both map to the "x" button should never be on the same object).
At this point, you can generate mouse UI or gamepad UI for any object or check if a particular key press is relevant to the object. You can also invoke a particular response event handler or generic script.
You should also consider how you select the "defualt" action for the mouse assuming you go with the interaction ideas above. You might give each interaction method an innate priority, such that the most "important" method (like attack) is always the default. You might just use the first one listed on an item definition. You might allow the item definition to assign priorities. You might allow the item definition to just explicitly set a default. I would prefer anything explicit since it allows items to have no default, which is good if you want objects that should not be accidentally actionable but require a little more work. (for the mouse UI I presented, clicking an object with no default might do nothing or it might bring up the radial menu, your choice)
Lastly, consider supporting implicit actions. All enemies should have an implicit Attack->Combat action. Objects with inventories should have an implicit Open->Inventory action. Explicitly set actions that conflict with implicit ones should have priority.