Toggle to include tags from inferior quality dupes in search

[walramb]

Currently, when tags are added to an inferior copy after you've processed it as a dupe, that information is kind of lost to you.
I don't want everything automatically copied over at all times, but when searching I'd find it useful to have a toggle to include or ignore tags from inferior quality dupes.

This seems related to the #283 notion of "virtual" tags.
These virtual dupe tags could perhaps even be listed in the tag list, with a different background color, to make it obvious they're not "hard" tags?

[bbappserver]

The objective of duplicate merging is explicitly to shrink the amount of data you need to store and consider, so after you merge an old work the tags are copied over and the low quality copy should become irrelevant. It would be helpful if you could provide a use for why you still need to access this information.

The only reason I can think for why you might is if you wanted to filter out a source: namespace, and I believe excluding by namespace is already a feature of custom metadata merges.

I'm also not tags from inferior duplicates should also continue to exist they just aren't accessible as part of the UI... or at least that's how it goes with the PTR, maybe fr local tags if you delete the hash the tag mappings go poof.

[GoAwayNow]

Filtering namespaces when merging dupes is a feature, and IIRC, I believe that tag information is maintained in the local database after deleting.
That said, I can think of a good reason for this change: the PTR. If you have, say, a version of an image that is higher quality than the public version, tags may get added to the public version on the PTR, which would never make it to your higher quality version if you've already sorted it.

[walramb]

If you have, say, a version of an image that is higher quality than the public version, tags may get added to the public version on the PTR, which would never make it to your higher quality version if you've already sorted it.

This is the main use case I was getting at.
But I also have similar situations with tags that have been added to the "worse" files locally, after bulk importing large collections with sidecar .txt tags.
In general I think it would be a good thing to have more tools to make sense of tag commonalities/differences across existing file relationships, and this is just one possible addition to the tool belt.

[Zweibach]

I remember dev saying, a while ago by now, that he had plans to make Hydrus able to associate hashes and treat the dupe king as its lessers. One of the intended uses is to be able to get the PTR changes for the lessers just as @GoAwayNow talked about. I'll bring this issue up with dev when he pops in for the update chat.

[Zweibach]

According to dev this feature requires some reworking of the dupe system to be possible. It's somewhere off in the future but he does know about it.