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

This PR bumps Tree-sitter for
https://github.com/tree-sitter/tree-sitter/pull/2788.

Release Notes:

- Fixed a crash that could happen when opening certain large markdown
files.

Deals with https://github.com/zed-industries/community/issues/2295 and
https://github.com/zed-industries/community/issues/2296

Release Notes:

- Fixed excluded .git files appearing in worktree after FS events

Release Notes:

- N/A

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:

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

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

This PR fixes storybook and gets it back into a compiling and running
state.

Release Notes:

- N/A

[[PR Description]]

- Update default ui_font_size
- Update toolbar style
- Start on ui::Popover

Release Notes:

- N/A

This PR extracts the `Story` component into a separate `story` crate so
that it can be shared among various crates that define stories.

Release Notes:

- N/A

---------

Co-authored-by: Nate Butler <iamnbutler@gmail.com>

Co-Authored-By: Marshall Bowers <1486634+maxdeviant@users.noreply.github.com>

Co-Authored-By: Marshall Bowers <1486634+maxdeviant@users.noreply.github.com>

Co-Authored-By: Marshall Bowers <1486634+maxdeviant@users.noreply.github.com>

This PR gets the component stories defined in `ui2` compiling again.

Release Notes:

- N/A

# Conflicts:
#	crates/editor2/src/editor.rs

This PR fixes a panic that occurs when opening the settings in zed2.

We store the `ThemeRegistry` as a global without wrapping it in an
`Arc`, so we need to retrieve it the same way.

Release Notes:

- N/A

[[PR Description]]

Tidies up the `ui2` crate, removing all components we aren't using and
doing a bit of reorganization.

Release Notes:

- N/A

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>