fix: Incorrect flychecks with multiple workspaces

[Wilfred]

When rust-analyzer receives textDocument/didChangeWatchedFiles, we want to trigger a flycheck in all workspaces if we can't find which workspace owns those files.

However, since we used .any() instead of .all(), this behaviour was always triggered when the user had more than one workspace.

For cargo-based projects, this just makes rust-analyzer slower. For projects with a custom check command using $saved_file or {saved_file}, this introduced a race condition that sometimes prevented diagnostics.

When we see the following flycheck events in this order:

// Created by textDocument/didSave.
RequestStateChange(Restart { ... saved_file: Some("foo.rs") })
// Created by textDocument/didChangeWatchedFiles
RequestStateChange(Restart { ... saved_file: None })

Then the flycheck debounce takes the last event, we invoke flycheck with saved_file: None, and no flycheck occurs (because we require a value to substitute in $saved_file).

Previously the debounce took the first event (until #21666), but that just meant a race condition when events arrive in the opposite order.

Instead, use .all() and add an integration test to exercise this behaviour.

AI disclosure: Once I understood the problem, I used Opus 4.6 to do the first draft of this integration test.

[Wilfred]

Interesting, a macOS test is hanging due to no diagnostics. That sounds like #21571.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 08e9bcd

[Wilfred]

I can't reproduce the macOS failure on my mac laptop, I presume this is just a performance with GitHub's macOS CI. I've tweaked the timeouts, but as mentioned above I think a fix similar to #21571 is going to help, so I'll look at that too.