Show multi-domain translations in state-picker

[karwosts]

Proposed change

When we use a state selector w/ multiple entities, those entities could have the same common states with different translations.

For example if we have a state trigger with a moisture binary sensor and a light (newly added feature allows multiple entities), both of those entities have the state "on", but the state selector will offer the state options "Wet" or "Dry".

It is kind of odd that selecting the "Wet" option really means "when the light turns on", but that's how it will work in the backend.

It's still a bit strange result, but maybe we want to show all possible unique state translations of the common state, e.g.:

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[piitaya]

Should we encourage user to do that? IMO, if user want to trigger on light and binary_sensor, he/she should use multiple triggers.
That's why we are working to create trigger and condition by domain (e.g home-assistant/core#149819).
I'm not against this change but looks like it adds complexity to the UI for something we don't really want.

[karwosts]

Should we encourage user to do that?

I guess not really, but this would generally apply to any use of the state-picker, not just state trigger.

As we allow to to use arbitrary multiple entities for context, we kind of get into this weird situation where the UI is currently showing something which I think is not really correct.

This also show up in my other PR to use a state-picker in the logbook card.

[MindFreeze]

The UX team decided agains this @karwosts . There are too many issues with this kind of trigger (device_class, description, update on entity change, etc.) and the PR doesn't address all of them. And it's not worth addressing them frankly. Better to push users into separating these into multiple triggers