feat(deps): reference git instead of package

[sator-imaging]

This PR makes GPUI types interchangeable across multiple libraries.

For example, a consumer can use multiple libraries that depend on GPUI while overriding all of their GPUI dependencies to the same fork:

bezel = ...
bezel-editor = ...
other-gpui-lib = ...
gpui          = { git = "https://github.com/crabtalk/zed", version = ">=0.2.2" }
gpui_platform = { git = "https://github.com/crabtalk/zed", version = ">=0.1.0", features = ["font-kit"] }

# Override GPUI references to use the same fork.
[patch.crates-io]
gpui          = { git = "https://github.com/crabtalk/zed", version = ">=0.2.2" }
gpui_platform = { git = "https://github.com/crabtalk/zed", version = ">=0.1.0" }
gpui_web      = { git = "https://github.com/crabtalk/zed", version = ">=0.1.0" }

Problem / Motivation

[patch.crates-io] can override a dependency with another source, but it cannot redirect one crate name to a package with a different name (ex. gpui = { package = "bezel-gpui", ... }). Also, Cargo does not allow multiple patches for the same source with different package names (gpui = { git = SAME } bezel-gpui = { git = SAME }).

As a result, when multiple libraries use different GPUI-compatible crates, there is currently no way for consumers to make their GPUI types interchangeable, even when their APIs are otherwise compatible.

With this PR, a single window can contain controls from multiple libraries.

---

cargo nextest run is passed.

[clearloop]

this will be dangerous and won't work ))

our gpui fork and bezel are being bumped together always, e.g. bezel is the only cause of the version bump of bezel-gpui

if you are working on a fork, the better solution is either merging bezel from the official or do the git dep bump in the fork since most of bezel-gpui version bumps will break the old version of bezel, that's why we publish all of them to crates-io.

---

The other case would be that bezel is moving fast at 0.1.x, if that affects the downstream heavily atm, I'll do better version control for bezel, e.g. bump the minor version once there are breaking changes always, but I hope we can defer this for maybe one week, since that will slow down my development a lot )))

[sator-imaging]

I see. Right, the best solution is Cargo supports patching the multiple libraries instead of providing extension point in crate.