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.

Instead, use .all() so we correctly detect when the file it outside of
all workspaces.

---

For cargo-based projects, this just made 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 arrived in the opposite order.

[Wilfred]

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

[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.

[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.

[Wilfred]

OK, I've removed the integration test here as it's flaky. I think the logic is obviously correct -- it now matches the comment -- and it fixes the issue I'm seeing in my local testing.