Switch back to invalidating filter when receiving mod updates.

[Holt59]

1. I clean a bit the NXM-update slots because I did not like that sender stuff, so I just used a lambda.
   • The signal was incorrect (the template type of QFutureWatcher did not match), but I guess that was partially fine...
2. I switched back to invalidate in some cases, but I only invalidate at the end (there is no point invalidating for all mods).
   • I removed invalidate initially because it was breaking selection, etc., which was annoying. Now it does not, (probably) because I modified the by-priority proxy to not reset the model when not required.

I have no clue if this actually will fix the issue some users are experiencing because I still cannot reproduce it.

[Al12rs]

nxmModInfoAvailable() is still using notifyChange(), while before it was using invalidate. nxmModInfoAvailable() is called in case that the mod file is marked as deleted or Old but there is not a new file that is marked to be successor, so MO2 requests the general mod info for the mod version.

[Holt59]

nxmModInfoAvailable() is still using notifyChange(), while before it was using invalidate. nxmModInfoAvailable() is called in case that the mod file is marked as deleted or Old but there is not a new file that is marked to be successor, so MO2 requests the general mod info for the mod version.

Yes I know, but I think notifyChange is sufficient here. The one that is bothering me is https://github.com/ModOrganizer2/modorganizer/pull/1417/files#diff-c72b037f3ac7abbd3d0ee519b6f456013a9bbf5a59df16308939320c04970447R2831, but since I have no clue why it was (is?) needed, I added it back. The other I replaced was in a if (foundUpdate), similar to the one you already fixed. I don't really now why it would be needed in the else since you get the nxmModInfoAvailable afterward.