Vendored libgit2-sys builds fail on Windows when `cargo --manifest-path` is a long UNC path

Where "a long UNC path" is e.g. \\?\C:\...\some_project\Cargo.toml, which is the form emitted by std::path::Path::canonicalize on Windows.

Reproducing the error is very simple.

cargo init path_fun
cd path_fun
cargo add git2 --features vendored-libgit2
cargo build --manifest-path \\?\S:\...\path_fun\Cargo.toml
# replacing `S:\` with your drive, and `...` with a real path

The output is quite repetitive, yielding numerous lines similar to:

cargo:warning=ToolExecError: command did not execute successfully (status code exit code: 2): "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.44.35207\\bin\\HostX64\\x64\\cl.exe" "-nologo" "-MD" "-O1" "-Z7" "-Brepro" "-I" "\\\\?\\S:\\...\\target\\debug\\build\\libgit2-sys-7b3f8407131016e2\\out\\include" "-I" "libgit2/src/libgit2" "-I" "libgit2/src/util" "-I" "libgit2/deps/llhttp" "-I" "libgit2/deps/xdiff" "-I" "libgit2/deps/pcre" "-I" "\\\\?\\S:\\...\\target\\debug\\build\\libz-sys-f91fe522964cd50a\\out/include" "-W0" "-DGIT_REGEX_BUILTIN=1" "-DHAVE_STDINT_H=1" "-DHAVE_MEMMOVE=1" "-DNO_RECURSE=1" "-DNEWLINE=10" "-DPOSIX_MALLOC_THRESHOLD=10" "-DLINK_SIZE=2" "-DPARENS_NEST_LIMIT=250" "-DMATCH_LIMIT=10000000" "-DMATCH_LIMIT_RECURSION=MATCH_LIMIT" "-DMAX_NAME_SIZE=32" "-DMAX_NAME_COUNT=10000" "-DSTRSAFE_NO_DEPRECATE" "-DWIN32" "-D_WIN32_WINNT=0x0600" "-DSHA1DC_NO_STANDARD_INCLUDES=1" "-DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"common.h\"" "-DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"common.h\"" "-Fo\\\\?\\S:\\...\\target\\debug\\build\\libgit2-sys-7b3f8407131016e2\\out\\build\\43a19b30e9e69d8f-reader.o" "-c" "libgit2/src/libgit2\\reader.c"rebase.c
  S:\cargo\registry\src\index.crates.io-1949cf8c6b5b557f\libgit2-sys-0.18.3+1.9.2\libgit2\src\util\git2_util.h(11): fatal error C1083: Cannot open include file: 'git2_features.h': No such file or directory

The relevant sections, I believe, being Cannot open include file: 'git2_features.h': No such file or directory and "-I" "\\\\?\\S:\\...\\target\\debug\\build\\libgit2-sys-7b3f8407131016e2\\out\\include". Very notably, if I look in the ...\target\debug\build\libgit2-sys-7b3f8407131016e2\out\include I find git2_features.h. That leads me to imagine this is some dumb little shell expansion corner case.

I've confirmed this is reproducible (On My Machine™) in git2 v0.20.3 / libgit2-sys v0.18.3+1.9.2 through git2 v0.19.0 / libgit2-sys v0.17.0+1.8.1. (My CI systems have definitely built v0.19.0 just fine, but are bombing on v0.20.3, so I need to focus on fixing that issue.)

Note the same issue seems to be present in libssh2-sys v0.3.1, and depending on the resolved cargo build order, you might see Cannot open include file: 'libssh2.h' instead of git2_features.h with the above repro instructions. The libssh2-sys ToolExecError includes a mirrored "-I" "\\\\?\\S:\\...\\target\\debug\\build\\libssh2-sys-b28bdd3defa4ee0c\\out\\include" (almost) pointing to a directory that includes a libssh2.h. I didn't realize this until I was mostly done writing this issue and started seeing it out of my local repros. I can duplicate the report in the libssh2-sys github repo if that would be useful.

Thanks!

Reproduce the failure with cargo build --manifest-path using the long UNC path, then inspect the vendored libgit2-sys and libssh2-sys compiler commands and their out/include paths. Compare the affected 0.18.3/1.9.2 and older 0.17.0/1.8.1 builds; done means the generated headers are found and both vendored builds succeed from a long UNC path.