worktree: Improve performance with large # of repositories

[osiewicz]

In this PR we've reworked how git status updates are processed. Most notable change is moving the processing into a background thread (and splitting it across multiple background workers). We believe it is safe to do so, as worktree events are not deterministic (fs updates are not guaranteed to come in any order etc), so I've figured that git store should not be overly order-reliant anyways.

Note that this PR does not solve perf issues wholesale - other parts of the system are still slow to process stuff (which I plan to nuke soon).

Related to #34302

Release Notes:

• Improved Zed's performance in projects with large # of repositories

[osiewicz]

@cole-miller I've applied your feedback from #34460 (comment) with a small twist; we're not gonna walk preceding paths, as that exposes us to a potential O(n) behavior we're trying to avoid in the first place. Instead, we'll retry with a parent as a query. That way, we basically optimize against cases where there are multiple projects with a repository in a single parent - because we'll just skip over all siblings at the cost of doing one range search per parent. This should also terminate somewhat reliably, because we're bailing from this function if .last ever fails.

[osiewicz]

Gonna merge this optimistically. Give a shout if you feel like anything should be changed, Cole.