Finding Git directory was broken by adding GIT_DIR support in the general case

[mentalisttraceur]

A problem introduced by how GIT_DIR support was added: makes Eza find the wrong Git directory in some cases.

For any given path argument given to Eza:

1. ✓ If GIT_DIR is set, and the path is inside that Git repo, great!

2. :x: If GIT_DIR is set, but the path is outside that Git repo, Eza lies: it prints the git status column but every line shows -- as if there are no changes (the status check is done against the wrong repo; Eza never tried finding the Git repo for that path, since it found the one at GIT_DIR and was satisfied).

   1. :x: If the path is in a different Git repo, the ideal behavior would be to show the correct Git status.
   2. :x: If the path is not in any Git repo, the ideal behaviour would be to not even show the Git column.

3. ✓ If GIT_DIR is set to something that's not a gitdir, great! (git2::Repository::open_from_env returns a not-found error, so Eza falls through to trying to normal git repository lookup on the path.)

   1. ✓ If the path is in a Git repo, the normal lookup finds it and shows the correct Git status.
   2. ✓ If the path is not in a Git repo, the Git column is correctly omitted.

4. :x: If GIT_DIR is not set, git2::Repository::open_from_env will try searching from the current directory (instead of searching from the given path), so:

   1. ✓ if eza was executed inside a Git repo, and the path is inside the same repo, great (by coincidence)!

   2. :x: if eza was executed inside a Git repo, and the path is outside that repo, Eza lies (same as case 2).

   3. ✓ if eza was executed outside of a Git repo, great!

In particular, note that last :x: case is a regression: even if a user doesn't use GIT_DIR, if they just happen to be inside a Git repo when they run Eza, the output will now show wrong status information for paths outside that repo (potentially importantly wrong! eza -l --git ../foo is something a user might run before deciding to rm -r ../foo based on the status infomation!) I'm surprised there wasn't a test to catch this in the automated tests (or maybe there is, but it's in the Vagrant tests which no one seems to be able to run)?