Deals with https://github.com/zed-industries/community/issues/1898

Restores original close behavior from
https://github.com/zed-industries/zed/pull/2832/files#diff-89af0b4072205c53b518aa977d6be48997e1a51fa4dbf06c7ddd1fec99fc510eL444
(load diff for the last file, zed.rs)

and adds a better name for the variable.

Release Notes:

- Fixes `cmd-q` not working

This PR fixes two bugs we discovered in Zed's mouse event handling while
investigating an interesting and mysterious bug we we were seeing, where
spurious `MouseMoved` events would continuously be dispatched after
control-clicking.

Release Notes:

- Fixed a rendering glitch that could occur after control-clicking
certain elements.

This adds IBM Plex as a font option available to use as `ui_sans`

Note: This PR adds a static list of accepted font types in `/font`, as
LICENSE files were causing the app to crash when Zed was trying to load
them as fonts.

Release Notes:

- N/A (No user facing changes)

Thanks @ForLoveOfCats for getting me unstuck ❤️

Co-Authored-By: Julia <30666851+ForLoveOfCats@users.noreply.github.com>

Co-Authored-By: Julia <30666851+ForLoveOfCats@users.noreply.github.com>

(base) natebutler@Nate16 zed % cargo run
   Compiling zed v0.99.0 (/Users/natebutler/Code/zed/zed/crates/zed)
    Finished dev [unoptimized + debuginfo] target(s) in 9.15s
     Running `target/debug/Zed`
Thread "main" panicked with "called `Result::unwrap()` on an `Err` value: parse error" at crates/zed/src/main.rs:667:10
   0: backtrace::backtrace::libunwind::trace
             at /Users/natebutler/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.68/src/backtrace/libunwind.rs:93:5
      backtrace::backtrace::trace_unsynchronized
             at /Users/natebutler/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.68/src/backtrace/mod.rs:66:5
   1: backtrace::backtrace::trace
             at /Users/natebutler/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.68/src/backtrace/mod.rs:53:14
   2: backtrace::capture::Backtrace::create
             at /Users/natebutler/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.68/src/capture.rs:176:9
   3: backtrace::capture::Backtrace::new
             at /Users/natebutler/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.68/src/capture.rs:140:22
   4: Zed::init_panic_hook::{{closure}}
             at crates/zed/src/main.rs:436:29
   5: std::panicking::rust_panic_with_hook
   6: std::panicking::begin_panic_handler::{{closure}}
   7: std::sys_common::backtrace::__rust_end_short_backtrace
   8: _rust_begin_unwind
   9: core::panicking::panic_fmt
  10: core::result::unwrap_failed
  11: core::result::Result<T,E>::unwrap
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/result.rs:1089:23
  12: Zed::load_embedded_fonts
             at crates/zed/src/main.rs:664:5
  13: Zed::main
             at crates/zed/src/main.rs:80:5
  14: core::ops::function::FnOnce::call_once
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/core/src/ops/function.rs:250:5
  15: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/sys_common/backtrace.rs:134:18
  16: std::rt::lang_start::{{closure}}
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/rt.rs:166:18
  17: std::panicking::try
  18: std::rt::lang_start_internal
  19: std::rt::lang_start
             at /private/tmp/rust-20230613-7622-103lepv/rustc-1.70.0-src/library/std/src/rt.rs:165:17
  20: _mai

I want to use this on another branch, but it's a sweeping change, so
this prepares the ground for it. This can always be reverted if it
doesn't work out.

I went to add in `zprofile` to the bash language config to get syntax
highlighting for it. After adding it in, Zed was still not highlighting
the file. I checked and saw that we are using `Path::extension()` in
`language_for_file()`, which [returns `None` when a file's name begins
with a
`.`](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.extension),
such as in the case of `.zprofile`. This PR adds a custom method, with
some tests, that just tries to grab the last component in the file name
if `Path::extension` returns `None`. Not sure if `ext` is the best name,
but I can't use `extension`.

Maybe this method should be called `extension_or_hidden_file_name()`?

Release Notes:

- Fixed a bug where language detection would fail for files starting
with `.` in their names.
- Added syntax highlighting for `.zprofile` files

Co-authored-by: Mikayla <mikayla@zed.dev>

Co-authored-by: Mikayla <mikayla@zed.dev>

With this PR, I've eliminated almost all references to window ids
outside of the internals of GPUI. All public methods taking these ids
are now defined on `AnyWindowHandle`, which provides a more coherent
narrative around windows as a concept.

/cc @nathansobo @maxbrunsfeld 

Release Notes:
- Fixed scrollbar selections causing noticeable slowdowns with large
quantities of selections.

Release Notes:
- N/A (Internal theme stuff)

Instead, we now call this on window handles.

Rename selected_rows to background_highlight_row_ranges.
Do not return any ranges if there are more than 50k results

When editing rust code, the project diagnostics view sometimes fails to
update, so that you have to close the view and re-open it to see the
correct state.

This PR fixes one possible cause of that problem. There was an async
step in between *receiving* diagnostics from the language server and
updating the diagnostics, due to an async call to
`LspAdapter::process_diagnostics`. This could cause the following
sequence of events to happen:

1. Rust-analyzer sends us new diagnostics for a file `a.rs`
2. We call `process_diagnostics` with those diagnostics
3. Rust-analyzer sends us a `WorkDoneProgress` message, indicating that
the "flycheck" (aka `cargo check`) process has completed
4. We update the project diagnostics view due to this message.
5. The `process_diagnostics` call for `a.rs` completes
6. 💥 We have the new diagnostics for `a.rs`, but do not update the
project diagnostics view again.

This PR fixes this bug by simply making `process_diagnostics`
synchronous. There is no I/O or expensive computation happening in that
method. If we need to make it asynchronous in the future, we need to
introduce a queue that ensures that `publishDiagnostics` and
`workDoneProgress` messages are processed serially.

Release Notes:

- Fixed a bug where the project diagnostics view would sometimes fail to
update properly when using Rust-analyzer.

Release Notes:

- Added syntax highlighting for `Cargo.toml` files