Suppress filter updates for unchanged semantic search meaning

[HebaruSan]

Problem

If you manually type a search for is:compatible (or various other similar searches like not:compatible, is:cached, etc.) rather than clicking the check/X buttons in the dropdown, the UI responds very sluggishly on Windows.

Notably, this doesn't happen for something like dep:kopernicus or searching for fragments of a name, where each keystroke is pretty snappy.

Cause

A search for is:compatibl (note the missing e at the end) or any shorter substring is the same as an empty search, because we parse the is: prefix first and check whether the suffix matches any of our known strings, and if it doesn't, we just discard that part of the search. However, the UI still treats this as if it was a new search that needs a refresh at each keystroke, so we call ManageMods.UpdateFilters and re-generate the list. Since no mods are filtered out, this takes a while, especially when it happens repeatedly while you are typing.

For dep:kopernicus: d, de, and dep:k each filters the list significantly, so the refresh is quick enough to keep up with user keystrokes.

Linux and Mac appear to be unaffected because they use a timer to delay searches.

Changes

Now we only update the filters if the new searches have a different semantic meaning than the old searches. So while you are typing is:compatibl, each intermediate search is determined to be equivalent to the default empty search, so nothing happens until you add the final e, at which point we show the list of compatible mods, which is quick because it's a shorter list.

To do this, ModSearch.Equals is now defined to return whether two searches have the same meaning, and ModList.SearchesEqual is a short wrapper around SequenceEqual to handle nulls. We only trigger a full refresh if SearchesEqual returns false.

Fixes #3402.

[DasSkelett]

Makes sense, looks good