This is just a buffer search (without project search), as the latter
needs a multibuffer from `editor`
Release Notes:

- N/A

This is an exploration of what it would take to remove the `V` generic
from the element type. Answer: less than I expected.

I added a new struct to GPUI2: `CallbackHandle<Event>`, and reworked the
interactivity related APIs to take this type. I also added a
`.callback()` function to `ViewContext` that can construct a
`CallbackHandle` to wrap our current `|&mut View, &Evt, &mut
ViewContext| {...}` based APIs. With these two changes, we can now
capture the context of the callsite of a click handler, allowing us to
capture all relevant types and data _before_ sending them into GPUI.
This lets us achieve a similar programing style to the existing system,
while also letting us remove all of the generics from the entire element
system. For an example of what this looks like in practice, here's a
side by side diff of the test in `interactive.rs` (which compiles and
passes):

<img width="1310" alt="Screenshot 2023-11-19 at 7 32 08 PM"
src="https://github.com/zed-industries/zed/assets/2280405/596f2a9a-9c8e-4158-bf6d-0003cf973015">

Note how the new arrangement of types is more amenable to rust's type
inference, allowing the code to be just as terse as before despite the
extra function call in the middle.

This approach also allows components to provide well typed APIs to
views, without ever knowing that view's type. This PR includes an
example rewrite of the button component in `ui2`, here's what it's
struct could look like now:

<img width="1105" alt="Screenshot 2023-11-19 at 7 24 28 PM"
src="https://github.com/zed-industries/zed/assets/2280405/fc98d3c2-6831-4c0f-a324-ab0fae33b0bc">

However, I have not yet ported the derive macro for Component to this
new structure, as I know @nathansobo is currently reworking that code.

Once that macro has been rewritten, it should be relatively easy to
rewrite the rest of Zed2 with this approach, the only major difference
that I can foresee is that the editor element would need to wrap it's
operations in an update callback. Though I can think of a few ways to
fix this with a new `ViewElement` trait, that does the wrapping for you.

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

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

[[PR Description]]

Adds `script/deploy-docs`:
- If you don't already have it, it will clone the `zed-docs` repo into
`../zed-docs`
    - It will build the docs and output them in `../zed-docs`
    - Then it will open the docs.
- By default this "dry runs" (doesn't push) but you can pass `-p` to
push the changes.
    - If you add `-c` it will clean out the old docs before running.
    
If you run the script with `p` it will push up the changes, and vercel
will automatically deploy them.

Release Notes:

- N/A

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

This PR renames the `ListEntry` component to `ListItem` to better
reflect its intent.

Release Notes:

- N/A

If we find a previous installation_id, then we send `open`. If we don't find a previous installation_id, then we sent as `first open`. If we fail, we mark it as `open` so that we don't accidentally bloat our `first open` stats.

When running `script/bundle` with the new `-2` flag, we needed to adjust
the fat-binary creation step to look for the binary called `Zed2`.

We also fixed a source of intermittent build failures in `script/bundle`
due to running multiple `swift build` processes concurrently for the
`live_kit_client2` crate, building for the two architectures.

Release Notes:

NA

Co-authored-by: Julia <julia@zed.dev>

This PR reworks the `List` component to use `children` instead of
accepting a `Vec<ListItem>` in its constructor.

This is a step towards making the `List` component more open.

Release Notes:

- N/A

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

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

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

This PR changes `Element::paint` to move self and introduces a new
`RenderOnce` trait, which renders into an element by moving self.
Elements are required to be `RenderOnce`, and `element_id` is now on
`RenderOnce` so we can get the id without moving self. The `child` and
`children` methods now expect `impl RenderOnce`.

```rust
pub trait Element<V: 'static>: 'static + RenderOnce<V> {
    type State: 'static;

    fn layout(
        &mut self,
        view_state: &mut V,
        element_state: Option<Self::State>,
        cx: &mut ViewContext<V>,
    ) -> (LayoutId, Self::State);

    fn paint(
        self,
        bounds: Bounds<Pixels>,
        view_state: &mut V,
        element_state: &mut Self::State,
        cx: &mut ViewContext<V>,
    );

    fn into_any(self) -> AnyElement<V> {
        AnyElement::new(self)
    }
}

pub trait RenderOnce<V: 'static>: Sized {
    type Element: Element<V> + 'static;

    fn element_id(&self) -> Option<ElementId>;

    fn render_once(self) -> Self::Element;

   // default helpers ...
}
```

To make a type a component, you can add `#[derive(RenderOnce)]`, which
will require your type to implement the `Component` trait:

```rust
pub trait Component<V: 'static>: 'static {
    type Rendered: RenderOnce<V>;

    fn render(self, view: &mut V, cx: &mut ViewContext<V>) -> Self::Rendered;
}
```

I'm satisfied with this being what we open source for elements, aside
from maybe adding a `StatefulComponent` trait that uses element state.
Things finally feel like they slot into a coherent and simple narrative.

Release Notes:

- N/A