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

Removes empty hovers from appearing:

![image](https://github.com/zed-industries/zed/assets/2690773/b8a8af17-e20f-4d87-8782-465dfbf9b561)

And trims final hover label to ensure no trailing whitespaces are
present:

![image](https://github.com/zed-industries/zed/assets/2690773/24aeb0f0-d4f0-4e2b-9265-53694bfec437)


Release Notes:

- Tidies up hover elements by trimming them and removing the empty ones

Co-authored-by: Kyle <kyle@zed.dev>

Co-authored-by: Kyle <kyle@zed.dev>

This change accidentally slipped into https://github.com/zed-industries/zed/pull/2746

Release Notes:

- N/A

Release Notes:

- Added syntax highlighting for Bash, Shell Scripts

This will help cases where Node is broken causing Copilot to fail to
start but because it doesn't install via NPM we would not have caught it
prior.

Release Notes:
- Improved detection of broken Node installation impacting Copilot
([#1551](https://github.com/zed-industries/community/issues/1551)).

This will help cases where Node is broken causing Copilot to fail to
start but because it doesn't install via NPM we would not have caught
it prior.

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

Release Notes:

- Added syntax highlighting & Intelephense LSP support for PHP language.
([#46](https://github.com/zed-industries/community/issues/406)).

Code snippet
```rust
fn main() {
    //√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√√
}
```

has length of 191, but consists of 87 chars, and the debug code with
`.truncate(100)` panicked.
Fixed that issue, cc @KCaverly 


Release Notes:

- N/A

Avoid panicking when truncating code with special chars

Co-authored-by: Kyle <kyle@zed.dev>

Also remove unneeded mappings in `g` and `z` modes

Release Notes:

- Adds `ctrl+[` as an alias for escape
([#538](https://github.com/zed-industries/community/issues/538)).

Also remove unneeded mappings in `g` and `z` modes

Fixes: zed-industries/community#358

Fixes:
https://linear.app/zed-industries/issue/Z-2416/improvements-to-feedback-submission

We get a lot of duplicate messages through our in-app feedback. My best
guess is that because we do not tell the user we are doing anything, and
because submission takes awhile, users are hitting the submission button
mutliple times. This PR blocks the submission code, once an initial
submission is sent. If the original submission fails, we unblock the
submission code. The submit button is disabled and enabled accordingly
as well.

Release Notes:

- N/A

Fixes https://github.com/zed-industries/community/issues/1760

Release Notes:

- Add option for chosing where the close button should be displayed on
editor tabs

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

Fixes https://github.com/zed-industries/community/issues/1674

Release Notes:

- Added option for showing git status on editor tabs

Follow-up of https://github.com/zed-industries/zed/pull/2678
Deals with https://github.com/zed-industries/community/issues/772

Refreshes macOs menu panel on keymap file change and properly ignore
disabled actions.

Release Notes:

- Fixes a bug when disabled actions from macOs menu were still working

Spent a bit in a deep dive into how to handle this and honestly the
situation is rather unfortunate. The core problem is that when we have a
panic anywhere we need to tear down the app, and we'd like to do that as
cleanly as possible, avoiding throwing any other panics along the way if
possible.

We've been seeing a number of panics being reported which are
nonsensical, seemingly pointing to being a fallout panic from a worker
thread panic-ing, at which point we would write multiple panics to the
panic file, and we could possibly upload either both or the wrong panic
causing a wild goose chase. Unfortunately I've been entirely unable to
reproduce the specific panic we've been seeing but I was able to read
through the code responsible and confirm that under specific situations
a panic on one worker can cause another worker or the main thread to
also panic.

An easy solution to this is just to ignore any panics after the first
one. I'm thinking that *hopefully* we can trust the first panic to reach
the panic hook first so that the flag doesn't accidentally filter out
the panic we actually care about.

That being said we were expecting that to have already been the case
about which panic gets written to the panic file first, the first one in
the file being the one we upload, which doesn't seem to have been the
case. I'm hoping it was IO silliness causing that and that the flag
shouldn't be race-y, however this is still a shot in the dark. 🤞

As for cleanly shutting down, there's not really much we can do. One
thread physically cannot cause another to unwind without somehow sending
a message which isn't super useful. The only way for a thread to shut
down all threads and the process is to go nuclear and abort/exit the
process. This will never unwind other threads, effectively having the
same effect on those threads as compiling with `panic = "abort"` would.

With some (mis)use of `std::panic::resume_unwind` we can at least say
that for whatever thread actually panic-ed we will unwind, and any other
threads that panic as a result will probably get at least partway
through unwinding. This is weird, almost a combination of panic
rewinding and aborting, and may actually be worse than just biting the
bullet and aborting immediately.

I'm really not a fan of where I've ended up but it does seem to at the
very least an improvement. The main question in my mind at this point is
whether it would be better to attempt to unwind what we can or go all in
on abort. I'd love some input on that.

Release Notes:
- Improved panic reporting when a background thread panics.

co-authored-by: Max Brunsfeld <max@zed.dev>