Restructure MatchAny seeding limit evaluation logic

[V0latyle]

Closes #24500

Current MatchAny behavior is to match any limit that is met first - even if Seeding Time is set for a longer time (i.e., 7 days) than Inactive Time (24 hours).

This restructures Match Any to require that either Ratio or Seeding Time (if set) be satisfied before Inactive Time takes over.

ETA will also correctly reflect time to target.

[glassez]

Current MatchAny behavior is to match any limit that is met first

...which exactly corresponds to its name.

[glassez]

This restructures Match Any to require that either Ratio or Seeding Time (if set) be satisfied before Inactive Time takes over.

In that case, it is no longer "match any" and you should choose a more appropriate name for it.
Moreover, I believe that the current "match any" behavior may still be suitable for someone else, so I would not replace it with another one, but add yet another option instead.

[V0latyle]

This restructures Match Any to require that either Ratio or Seeding Time (if set) be satisfied before Inactive Time takes over.

In that case, it is no longer "match any" and you should choose a more appropriate name for it. Moreover, I believe that the current "match any" behavior may still be suitable for someone else, so I would not replace it with another one, but add yet another option instead.

That's fair, but my logic was this: Most users use "inactive time" as a gatekeeper to time out torrents that are no longer active, after meeting primary seeding targets, not as a primary target itself. Should a user want the torrent to only seed for a given inactive time, they can set Ratio and Seed Time to "Unlimited" or zero.

On the latest CI, I had been using "MatchAll" mode with ratio set to unlimited, then seeding time and inactive time set as desired. But, I wanted the option to still use a ratio target without requiring that the torrent meet the seeding time target.

Also, I wanted to keep the UI fairly clean. So it made more sense, at least to me, for it to be an "under the hood" change.

But yes, in the interest of not changing core behavior without giving users the option to use it in the original manner, it would probably be a good idea. I'll see what I can do. Thanks for taking a look.