Don't emit event when LSP reports consecutive empty diagnostics

This is related to #849: in that pull request we avoided *storing*
empty diagnostics, but we'd still report an event when receiving
consecutive empty diagnostics. So if the project diagnostics editor
was open, it could happen that opening a buffer would cause the
language server to report zero diagnostics. We would therefore close
the buffer because there were no diagnostics, but doing so would cause
the LSP to report another event with zero diagnostics. This would repeat
forever, causing Zed to use a lot of CPU and the UI not to refresh properly.

With this commit we will simply avoid emitting a `DiagnosticsUpdated` event
altogether if no diagnostics were present before *and* the LSP is reporting
a `PublishDiagnostics` event with no diagnostics in it.

File finder fixes

The file finder often cancels an in-progress match task when
the project updates. But it still needs to take the matches
that it did find and add them to its results. So we should
not cancel the entire task, as this will cause the
partial results to be discarded.

Co-Authored-By: Antonio Scandurra <me@as-cii.com>
Co-Authored-By: Keith Simmons <keith@the-simmons.net>
Co-Authored-By: Max Brunsfeld <maxbrunsfeld@gmail.com>

Co-Authored-By: Antonio Scandurra <me@as-cii.com>

Remove summaries that don't contain any errors or warnings

When opening a buffer, some language servers might start reporting
diagnostics. When closing a buffer, they might report that no diagnostics
are present for that buffer. Previously, we would keep an empty summary entry
which would cause us to open a buffer in the project diagnostics view, only to
drop it because it contained no diagnostics. However, the act of opening it
caused the language server to asynchronously report non-empty diagnostics.
We would therefore handle this as an update, but the previous closing of the
buffer would cause the language server to report empty diagnostics again. This
would cause the project diagnostics view to thrash infinitely between these two
states, pegging the CPU and constantly refreshing the UI.

With this commit we won't maintain empty summary entries for files that contain
no diagnostics, which fixes the above issue.

Co-Authored-By: Nathan Sobo <nathan@zed.dev>

Use the entire `ProjectPath` to find open buffer for an LSP diagnostic

Previously, we would only compare the path relative to the worktree root, which
would cause Zed to sometimes update diagnostics on the wrong buffer. This
manifested in the project diagnostics not showing those errors/warnings while
the status bar and the tab title displayed a summary with errors/warnings.

This commit simply uses `Project::get_open_buffer` which correctly locates a
buffer with the given project path.

Command palette

Also add a unit test for the command palette

Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Keith Simmons <keith@zed.dev>

Co-authored-by: Keith Simmons <keith@zed.dev>

Co-authored-by: Keith Simmons <keith@zed.dev>

They still need to be styled.

Co-authored-by: Antonio Scandurra <me@as-cii.com>

update feature color in dark theme

Add javascript and jsx specific languages

Add c and d operators to vim normal mode

Extracted motions from normal mode
Changed vim_submode to be vim_operator to enable better composition of operators

Always clear rename state when selections change

At some point during the implementation of rename, we added logic for
invalidating the rename state when the selection moved outside the original
rename range. After transitioning to displaying renames as a block decoration,
we don't need that anymore given that a new, temporary editor is used instead.

This commit removes that invalidation logic and always calls `Editor::take_rename`
when the editor selections change. Doing so also fixes a bug that was causing Zed
to hide the cursor when clicking on the editor to dismiss the rename.

Fix focus bugs in `ProjectSearchView`

Store accessors for editor highlight colors not colors themselves

...so that we can re-focus the previously-active editor when switching back
to the project search tab.

This allows us to focus the query editor of the project search when deploying it. Previously, a complex interplay between focus events was preventing this from working in an intuitive way. What happened previously:

- We'd activate the project search, which enqueued a focus effect for the project search view
- We'd focus the query editor, which enqueued an effect
- We'd process the focus effect for the search view, which would enqueue an effect to transfer focus to the results editor
- We'd process the effect to focus the query editor
- We'd process the effect to focus the results editor

Now...

- We activate the project search pane item, enqueuing a focus effect for the project search itself
- We focus the query editor and *remove* the previous pending focus change effect
- We process the focus effect

Speed up `WrapSnapshot::line_len` using the indexed transforms