cargo: enable vendored-libgit2, document how to properly dynamically link libgit2

This changes less than it seems. Our CI builds already mostly linked a vendored
copy of libgit2. This is because before this commit, it turns out that `git2`
could link `libgit2` *either* statically or dynamically based on whether it could
find a version of libgit2 it liked to link dynamically. Our CI builds usually did
not provide such a version AFAIK.

This made the kind of binary `cargo install` would produce unpredictable and may
have contributed to jj-vcs#2896.  I was once very surprised when I did `brew upgrade libgit2` and then
`cargo build --release` suddenly switched from building dynamically linked `jj` to the vendored version.

Instead, if a packager wants to link `libgit2` dynamically, they should set an
environment variable, as described inside the diff of this commit. I also think
we should recommend static linking as `git2` is quite picky about the versions of
`libgit2` it supports. See also rust-lang/git2-rs#1073

This might be related to jj-vcs#4115.

Author: ilyagr

Cargo.toml

@@ -48,7 +48,16 @@ dunce = "1.0.4"
 either = "1.13.0"
 esl01-renderdag = "0.3.0"
 futures = "0.3.30"
-git2 = "0.18.3"
+git2 = { version = "0.18.3", features = [
+    # Do *not* disable this feature even if you'd like dynamic linking. Instead,
+    # set the environment variable `LIBGIT2_NO_VENDOR=1` if dynamic linking must
+    # be used (this will override the Cargo feature), and allow static linking
+    # in other cases. Rationale: If neither the feature nor the environment
+    # variable are set, `git2` may still decide to vendor `libgit2` if it
+    # doesn't find a version of `libgit2` to link to dynamically. See also
+    # https://github.com/rust-lang/git2-rs/commit/3cef4119f
+    "vendored-libgit2"
+] }
 gix = { version = "0.63.0", default-features = false, features = [
     "index",
     "max-performance-safe",