When testing Zed locally, it's rarely necessary to log in the real with,
via Zed.dev and GitHub. We usually use `zed-local`. Since zed.dev is not
going to be open source (at least right away), this PR removes it from
our local development workflow.

* Remove zed.dev from the Procfile
* Change the `seed` script to not create an admin user for your
signed-in github user
* Instead have both `zed-local` and the `seed` script read from an
`.admins.json` file, which the user can create in order to customize who
they sign in as when running `zed-local`.
* Update all of the docs for building and developing zed.

@mikayla-maki and @nathansobo's contributions

Release Notes:

- N/A

When the `List` element's state is `ListState::reset()`, it eagerly
trashes it's cached element heights in anticipation of a prompt render.
But, due to the recent `display_layer` changes, that re-render is not
always forthcoming. This is a problem for `ListState::scroll()`, which
depends on these cached elements to correctly calculate the new logical
scroll offset.

Solutions we attempted:

- Cache the element heights and continue the scroll calculation 
- This was conceptually incorrect, reset should only be called when the
underlying data has been changed, making any calculation with the old
results meaningless.
- Lazily re-compute the element heights in scroll 
- Beyond being a non-trivial refactor, this would probably also cause us
to double-render the list in a single frame, which is bad.
- Cache the scroll offset and only calculate it in paint 
- This solution felt awkward to implement and meant we can't supply
synchronous list scroll events.
- Delay resetting until paint 
- This means that all of the other APIs that `ListState` supplies would
give temporarily incorrect results, worsening the problem

Given these issues, we settled on the solution with the least
compromises: drop scroll events if the state has been `reset()` between
`paint()` and `scroll()`. This shifts the responsibility for the problem
out of the List element and into consumers of `List`, if you want
perfectly smooth scrolling then you need to use `reset()` judiciously
and prefer `splice()`.

That said, I tested this by aggressively scrolling the Collab panel, and
it seems to work as well as it did before.

This PR also includes some initial testing infrastructure for working
with input from the platform and rendered elements.

Release Notes:

- N/A

Release Notes:

- N/A

co-authored-by: Nathan <nathan@zed.dev>

co-authored-by: Nathan <nathan@zed.dev>

co-authored-by: Nathan <nathan@zed.dev>

This PR fixes some file paths used in our stories that were still
referencing the `ui2` crate.

Release Notes:

- N/A

co-authored-by: Nathan <nathan@zed.dev>
co-authored-by: Conrad <conrad@zed.dev>

Instead, admins are specified using a JSON file, 'admins.json'. This file is
gitignored. If it is not present, there is a default list of admins in
'admins.default.json'.

This PR decreases the size of the timestamps in the assistant's
conversation editor.

Ideally we'd want to align the baseline of the timestamp text with the
text in the sender button. I spent a while trying to do this, but it
seems like it may be pretty tricky.

Release Notes:

- Decreased the size of timestamps in the assistant panel conversation
editor.

Now those handlers do not intercept events/actions when the buffer search bar is dismissed.

co-authored-by: Piotr <piotr@zed.dev>

co-authored-by: Piotr <piotr@zed.dev>

To be able to trigger them from search multibuffer excerpts.

There's a deadlock that we're seeing when joining a room, which we think
is a bug in the LiveKit client.

Also, we're still getting crashes when leaving calls:
https://github.com/livekit/client-sdk-swift/issues/299.

At this point, we believe both problems are due to recent changes to the
LiveKit swift sdk.

This happens a lot in guest workflows where they open the call with a
link and are jumped straight to a shared workspace.

Release Notes:

- Fixed opening the chat automatically in new windows

Release Notes:

- N/A

This happens a lot in guest workflows where they open the call with a
link and are jumped straight to a shared workspace.

Co-Authored-By: Thorsten Ball <thorsten@zed.dev>

This PR adds more documentation to the `collab` crate.

Release Notes:

- N/A

---------

Co-authored-by: Conrad <conrad@zed.dev>

This reverts commit 5730d0ef2107f2a10fe01595ce34f14f97e289ad.

This PR documents the public interface of the `vim` crate.

Release Notes:

- N/A

---------

Co-authored-by: Conrad <conrad@zed.dev>

FIx typos

This PR cleans out the README.md, moves most relevant build details to
`docs/src/developing_zed__building_zed.md`.

It also restructures and cleans up the Building Zed doc.

There are a number of outstanding TODOs to have this doc be ready for
external folks to be able to build Zed.

Release Notes:

- N/A

Co-Authored-By: Joseph T. Lyons <19867440+JosephTLyons@users.noreply.github.com>

Written by @iamnbutler 

This PR adds a basic CONTRIBUTING.md. It has a few links that need to be
added, which we marked as coming soon.

Here are a number of follow up tasks we need to do:

- [ ] Add CLA link
- [ ] Add public roadmap link
- [ ] Add link to channels doc once it is up
- [ ] Add link explaining how to find a channel related to your
contribution or or to create one

Release Notes:

- N/A

Co-Authored-By: Joseph T. Lyons <19867440+JosephTLyons@users.noreply.github.com>

Co-Authored-By: Joseph T. Lyons <19867440+JosephTLyons@users.noreply.github.com>

Co-Authored-By: Joseph T. Lyons <19867440+JosephTLyons@users.noreply.github.com>

This PR makes the channel buttons square.

Release Notes:

- Adjusted the shape of the channel buttons.

This PR adds the `color` crate, which will be the home of a number of
color-related utilities, and also acts as an interface between
[`palette`](https://crates.io/crates/palette) and the way `gpui` colors
work.

The goal of this crate is to centralize color utilities like mixing and
blending, building color ramps and sets of colors for state and more.

## Todo:

- [x] hex -> Color
- [x] Color mixing
- [x] Color blending using blend modes (overlay, multiply, etc)
- [ ] ~~Build color ramp from color~~
- [x] Build state set from color
- [ ] ~~Update Theme to use the color crate~~

Release Notes:

- None (Internal changes: Adds the `color` crate for working with
colors.)

In #3910 we made the welcome screen use the same background color as the
editor.

However, this later regressed in
cdd5cb16ed896b2ee3bbb041983ee7cb812f6991.

This PR fixes that regression and restores the correct color for the
welcome page.

Release Notes:

- Fixed the background color of the welcome screen.

Release Notes:

- Improves the rendering of the facepile in the titlebar with many
people

Release Notes:

- Fixes a bug where you could not use call controls after a project was
unshared

Release Notes:

- Fixed a bug allowing certain UI elements to render incorrectly when
overlapping.

This removes the terminal performance slightly by removing memmoves that
aren't needed after inlining a call.

It also removes a possibly unnecessary `String` allocation.

Release Notes:

- Improved terminal rendering performance by reducing allocations and
memory operations.

Co-authored-by: Antonio <antonio@zed.dev>

Before this change we wouldn't submit all possible primitives of the
same kind that are less-than the max order.

Result was that we would submit, say, 10 paths each in a separate batch
instead of actually batching them.

This was overly strict because even if the order of two different
primitives was the same, we could have still batched the 1st primitive
kind, if its implicit ordering was less than 2nd kind.

Example: say we have the following primitives and these orders

  5x paths, order 3
  2x sprites, order 3

Previously, we would submit 1 path, 1 path, 1 path, 1 path, 1 path, then
the sprites.

With this changes, we batch the 5 paths into one batch.

Release Notes:

- Improved performance when rendering lots of selection.