Adds app events (`first open` and `open`). For the time being, I'm
abandonding trying to add `close`, after running into many issues
trying. The code is in place for me to continue on that work, but at the
moment, we require having the telemetry settings in hand when calling
any of the methods that log an event, so we can honor the user's
preference for sending telemetry or not, but when running the
`on_app_close` method, to send off an app `close` event, the settings
are no longer available (probably the order of teardown?), which causes
some tests to end up failing. I'm not sure how to solve this. Maybe we
keep the settings on the telemetry struct and update it each time any
event is logged, then, on app shutdown, when logging the app `close`
event, we can use the stored version (idk).

Release Notes:

- N/A

Release Notes:

- N/A

Also opens the window on startup.

Release Notes:

-

Release Notes:

- N/A

This PR decouples `call2` from `workspace2` in order to improve our
compile times.
Why pick such a small, innocent crate as `call`? It depends on
`live_kit_client`, which is not-so-innocent and is in fact stalling our
clean builds.
In this PR, `call2` depends on `workspace2`; workspace crate defines a
`CallHandler` trait for which the implementation resides in `call`; it
it then all tied together in `zed`, which passes a factory of `Box<dyn
CallHandler>` into workspace's `AppState`.
Clean debug build before this change: ~1m45s
Clean debug build after this change: ~1m25s

Clean release build before this change: ~6m30s
Clean release build after this change: ~4m30s

~Gonna follow up with release timings where I expect the change to be
more impactful (as this allows 2/3 of the infamous trio of
"project-workspace-editor" long pole to proceed quicker, without being
blocked on live-kit-client build script)~.
This should have little effect (if any) in incremental scenarios, where
live_kit_client is already built.
[release
timings.zip](https://github.com/zed-industries/zed/files/13431121/release.timings.zip)

Release Notes:
- N/A

This reverts commit 6e4268a471749449fff232fab5d65fe38bab57b2.

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

Release Notes:

- Fixed a bug where Zed would continue to request documentation for
completion lists which were stale or no longer visible.

Release Notes:

- N/A

Co-Authored-By: Max Brunsfeld <max@zed.dev>

This PR reworks the `ListItem` component to accept `children` rather
than just a `Label`.

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

As part of this the `ContextMenu` was simplified to only construct the
various list components in `render` rather than holding them as part of
its state.

Release Notes:

- N/A

Release Notes:

- N/A

Release Notes:

- N/A

It looks like we should keep RUSTFLAGS consistent in CI if possible;
some commands augmented RUSTFLAGS with "-D warnings" which overrode
`.cargo/config.toml`, causing unnecessary rebuilds even for non-bundling
runs. Tl;dr: for the last few days our average CI time spiked
significantly.
There are several solutions:
- We can place `-D warnings` in our `.cargo/config.toml`. That's not a
good solution, because then you wouldn't ever be able to build Zed with
warnings locally. A true PITA!
- We can place another config.toml somewhere in the search path
(https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure)
and rely on the merging of properties. That way we can avoid having `-D
warnings` on developer machines while being able to override CI
behaviour at will.

This PR implements the latter approach by creating the new config file
manually. Ideally we should have it a a separate file in repository
that's moved into $HOME/.cargo on each CI run. Maybe we should even
place it somewhere more local to the checked out Zed version, as placing
it in a global spot is kinda bad too - what if we start building
multiple cargo projects on our CI machines?

Release Notes:

- N/A

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