search: Fix sort order not being maintained in presence of open buffers

[osiewicz]

In project search UI code we were seeing an issue where "Go to next
match" would act up and behave weirdly. It would not wrap at times.
Stuff would be weird, yo. It turned out that match ranges reported by
core project search were sometimes out of sync with the state of the
multi-buffer. As in, the sort order of
search::ProjectSearch::match_ranges would not match up with
multi-buffer's sort order. This is ~because multi-buffers maintain their
own sort order.

What happened within project search is that we were skipping straight
from stage 1 (filtering paths) to stage 3 via an internal channel and in
the process we've dropped the channel used to maintain result sorting.
This made is so that, given 2 files to scan:

• project/file1.rs <- not open, has to go through stage2 (FS scan)
• project/file2.rs <- open, goes straight from stage1 (path filtering)
  to stage3 (finding all matches) We would report matches for
  project/file2.rs first, because we would notice that there's an
  existing language::Buffer for it. However, we should wait for
  project/file1.rs status to be reported first before we kick off
  project/file2.rs

The fix is to use the sorting channel instead of an internal one, as
that keeps the sorting worker "in the loop" about the state of the
world.

Closes #43672

Co-authored-by: Smit Barmase heysmitbarmase@gmail.com

Release Notes:

• Fixed "Select next match" in project search results misbehaving when some of the buffers within the search results were open before search was ran.
• Fixed project search results being scrolled to the last file active prior to running the search.

[osiewicz]

/cherry-pick preview