Caching and changeset fixes

[HebaruSan]

Background

• If you click the download to cache option, a download progress screen appears, and then the whole mod list is regenerated just to keep the is:cached and not:cached filters updated
• If you click the purge from cache option, the is:cached and not:cached filters are not updated

Problems

• If you select to install some mods and then download or purge them, the changeset will show out of date information regarding whether they're cached
• It is inconsistent that downloading to cache updates the filters but purging from cache doesn't, given how similar these options otherwise are
• Regenerating the mod list after the download finishes is more work than necessary simply to keep the filters updated

Causes

• The changeset tab was (re)generating its visual list only when the underlying changeset data changed, and downloading or purging a mod left the old text unchanged

Changes

Core:

• Static method GroupByDownloads from Support multiple download URLs per module #3877 is moved from NetAsyncModulesDownloader to CkanModule because it can have uses outside of downloading
  • The inner loop is refactored into OneDownloadGroupingPass, which is used to implement a new instance method GetDownloadsGroup that returns all mods in the given sequence that share a download ZIP with the current mod, without generating the other groups

GUI:

• The changeset tab now (re)generates the visual list when it is activated, to ensure the entries are always up to date with the currently cached mods
• The download to cache option and the purge from cache option both now use CkanModule.GetDownloadsGroup to update the cached status of all the mods that share a download ZIP with the selected mod
• The purge from cache right click menu now updates filters, so the affected mods will disappear if is:cached is active
• The download to cache option now simply updates the filters instead of regenerating the entire GUI mod list, which will be quicker
• GUI.ModList's constructor no longer accepts a handler for its ModFiltersUpdated event; it's now a normal event, so calling code is updated to add handlers as needed, which will mean less jumping around the code to understand this aspect during maintenance.
  • The event no longer passes the ModList object as a parameter because calling code would already have access to it by virtue of subscribing to the event in the first place

[techman83]

That's a great QoL improvement, thanks @HebaruSan !