- Don't read "installation" config from `GIT_CONFIG`
   When `gix-path` runs `git config -l ...` to obtain the path of a
   configuration file to regard as being associated with the `git`
   installation itself, it now no longer allows `GIT_CONFIG` to affect
   this path.
   
   Previously, setting `GIT_CONFIG` would treat it as the path of a
   `GitInstallation` configuration file. Although it is possible that
   this may have been used intentionally, it was never documented, did
   not work reliably on all platforms, and carried significant
   disadvantages. This is most likely a non-breaking change.
   
   The disadvantages of treating a path in `GIT_CONFIG` as the path
   to a configuration file associated with the `git` installation
   were:
   
   - For `git`, the `GIT_CONFIG` environment variable *only* affects
     `git config` commands, and not other commands that use
     configuration variables (which are most `git` commands). But when
     `gix-path` would obtain a path from `git config -l ...` that came
     from `GIT_CONFIG`, that configuration file would be used
     anywhere, and not only `gix config` commands.
   
   - Even for `gix config`, it is not at all clear that the
     `GIT_CONFIG` environment variable ought to be honored, because
     `gix config` has a different interface from and is not meant to
     be a drop-in replacement for `git config`, and because this
     environment variable is only even supported by `git config` for
     historical reasons. (In `git config`, one should typically use
     `--file` instead.)
   
   - The installation path is generally the path of a high-scoped
     configuration file, usually the system scope or, with Apple Git
     on macOS, the "unknown" scope even higher than that (of a file
     located under `/Library` or `/Applications`). In contrast, the
     `GIT_CONFIG` environment variable is really command scope, since
     it is an alternative way of achieving the same goal as `--file`
     when running `git config`, which `git` supports only for backward
     compatibility.
   
   - On Windows, when `EXEPATH` is set in a way that indentifies a
     Git for Windows installation directory, which is typically the
     case in a Git Bash environment (and not otherwise), `GIT_CONFIG`
     is not used by the public `gix-path` functions that ordinarily
     get information from calling `git config -l ...`, because this
     call is not performed and instead the location of a configuration
     file associated with the installation is inferred from that
     value.
   
     Although this also applies to some other ways the environment
     affects the behavior of `git config -l ...`, it is much stranger
     for `GIT_CONFIG`, because whether `GIT_CONFIG` should be used
     does not intuitively seem like it should be related to what other
     sources of information are available; the semantics of
     `GIT_CONFIG` for `git` are to be ignored by most commands, but to
     always be used commands (`git config`) that do not ignore it.
   
   - The effect on finding other files associated with the
     installation, such as a gitattributes file, may be especially
     hard to reason about for `GIT_CONFIG`. Such paths are sometimes
     inferred from the path that `gix-path` reports. In particular,
     this is how `installation_config_prefix()` works.
   
   This change only prevents `GIT_CONFIG` from specifying an
   installation config file or suppressing the search for it. This
   does not affect how other `GIT_CONFIG_*` environment variables are
   used.

### Other

 - Update gitoxide repository URLs
   This updates `Byron/gitoxide` URLs to `GitoxideLabs/gitoxide` in:
   
   - Markdown documentation, except changelogs and other such files
     where such changes should not be made.
   
   - Documentation comments (in .rs files).
   
   - Manifest (.toml) files, for the value of the `repository` key.
   
   - The comments appearing at the top of a sample hook that contains
     a repository URL as an example.
   
   When making these changes, I also allowed my editor to remove
   trailing whitespace in any lines in files already being edited
   (since, in this case, there was no disadvantage to allowing this).
   
   The gitoxide repository URL changed when the repository was moved
   into the recently created GitHub organization `GitoxideLabs`, as
   detailed in #1406. Please note that, although I believe updating
   the URLs to their new canonical values is useful, this is not
   needed to fix any broken links, since `Byron/gitoxide` URLs
   redirect (and hopefully will always redirect) to the coresponding
   `GitoxideLabs/gitoxide` URLs.
   
   While this change should not break any URLs, some affected URLs
   were already broken. This updates them, but they are still broken.
   They will be fixed in a subsequent commit.
   
   This also does not update `Byron/gitoxide` URLs in test fixtures
   or test cases, nor in the `Makefile`. (It may make sense to change
   some of those too, but it is not really a documentation change.)

### Commit Statistics

 - 10 commits contributed to the release over the course of 46 calendar days.
 - 46 days passed between releases.
 - 2 commits were understood as [conventional](https://www.conventionalcommits.org).
 - 0 issues like '(#ID)' were seen in commit messages

### Commit Details

 * **Uncategorized**
    - Merge pull request #1624 from EliahKagan/update-repo-url (795962b)
    - Update gitoxide repository URLs (64ff0a7)
    - Merge pull request #1594 from EliahKagan/comments (ab8880f)
    - Expand and clarify "unkown" scope comment in `git_cmd` (1526b01)
    - Merge pull request #1583 from EliahKagan/config-origin-env (130db3b)
    - Don't read "installation" config from `GIT_CONFIG` (eb72d31)
    - Fix the `never_from_git_config_env_var` test (f8e38d0)
    - Start testing that installation config is not from `GIT_CONFIG` (340ff37)
    - Unset other `GIT_DIR` related env vars in `git config -l` (01a412f)
    - Merge pull request #1582 from Byron/gix-path-release (93e86f1)