Honour GIT_INDEX_FILE so hook processes can operate on git's temporary index

[Adam Bouqdib (abemedia)]

git's hook protocol passes the index to operate on via GIT_INDEX_FILE (githooks(5)). For git commit -a and git commit <paths> this is a temporary index, not git_dir/index, and git holds the real index's lock for the duration of the commit.

gix has no way to honour this: index_path() is hardcoded to git_dir/index, and open_with_environment_overrides() reads only GIT_DIR and GIT_WORK_TREE. A gix-based pre-commit hook therefore sees an empty staged set under git commit -a (silently does nothing), and fails to lock the index under git commit <paths> (git holds it). libgit2 honours the variable for comparison.

Proposal, with index_path() as the single choke point so all internal consumers (index opening/caching, status, filter pipeline) pick it up for free:

1. open::Options gains an explicit override, e.g. index_file(path).
2. index_path() returns the override when set.
3. open_with_environment_overrides() also reads GIT_INDEX_FILE (gated by gix-sec permissions like the other env vars), absolutising relative values against the cwd at open time.

A nonexistent override file should keep the usual empty-index semantics, and bare repos are unaffected.
Happy to contribute the PR if the direction is acceptable.

[Sebastian Thiel (Byron)]

Thanks for letting me know and for the initial research!

The goal of making gix usable in hooks is valuable, and the approach sounds very reasonable.
I'd be looking forward to that PR 🙏.

[Adam Bouqdib (abemedia)]

Fixed by #2895