Release notes:

- `mute_on_join` setting now defaults to false.
- Right click on a channel to "Copy Channel Link", these links work to
open Zed and auto-join the channel

Blocked on: https://github.com/zed-industries/zed.dev/pull/388

Co-Authored-By: Antonio Scandurra <antonio@zed.dev>

Co-Authored-By: Antonio Scandurra <antonio@zed.dev>

Hopefully this works the first time 😅

Release Notes:

- N/A

For zed-industries/community#759
For zed-industries/community#1966

Co-Authored-By: Julia <floc@unpromptedtirade.com>

Participants' locations might momentarily reference projects that have already been unshared.

This normally doesn't happen, but it can happen if a participant
loses connection ungracefully, restarts their app, and then
explicitly joins again.

New rustc messages look like

```
thread 'tests::test_history_items_vs_very_good_external_match' panicked at crates/file_finder/src/file_finder.rs:1902:13:
assertion `left == right` failed: Only one history item contains collab_ui, it should be present and others should be filtered out
  left: 0
 right: 1
```

now and we fail to parse that `13:` bit properly, fix that.

One caveat is that we highlight the entire word including the trailing
`:`:
<img width="914" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/d653a8ff-3e6e-4e3d-b6ea-dad0c8db0f06">

this is unfortunate, but better than nothing (as now).
This is due to the fact, that we detect words with regex inside the
`terminal.rs` and send events to other place that's able to check paths
for existence (and whether that's a path at all), currently there's no
way to detect a path and sanitize it in `terminal.rs`

Release Notes:

- N/A

New rustc messages look like

```
thread 'tests::test_history_items_vs_very_good_external_match' panicked at crates/file_finder/src/file_finder.rs:1902:13:
assertion `left == right` failed: Only one history item contains collab_ui, it should be present and others should be filtered out
  left: 0
 right: 1
```

now and we fail to parse that `13:` bit properly, fix that.

I've also simplified the representation of a workspace's leaders, so
that it encodes in the type that there can only be one leader per pane.

Release Notes:

- Fixed a bug where you could accidentally follow multiple collaborators
in one pane at the same time.

Follow-up of https://github.com/zed-industries/zed/pull/3059 

Before: 

![image](https://github.com/zed-industries/zed/assets/2690773/4eb2d2d1-1aa3-40b8-b782-bf2bc5f17b43)

After:

![image](https://github.com/zed-industries/zed/assets/2690773/5587d46b-9198-45fe-9372-114a95d4b7d6)

Release Notes:

- N/A

This PR introduces a new script for running Zed against a local collab
server, called `script/zed-local`. This script replaces the two existing
scripts that we had for this purpose: `script/zed-with-local-servers`
and `script/start-local-collaboration`.

By default, the script starts one single instance of Zed, but you can
pass a numeric flag to start 1, 2, 3 or 4 instances. So to start up two
instances side by side, (like `start-local-collaboration` script), you'd
do this:

```
script/zed-local -2
```

But you can also start *three* (or even four) instances, each taking up
a quarter of the screen, like this:

```
script/zed-local -3
```

Like before, you can pass other arguments to the script, and they will
be passed through to the first zed instance.

Also, unlike the `start-local-collaboration` script, this script now
requires a call to GitHub to determine your GitHub username. It just
logs you in as Nathan by default, unless you set `ZED_IMPERSONATE`
explicitly.