bug-fix paths when PWD has a symlink in it
bug-fix paths when PWD has a symlink in it

Short version: forcibly unset `$PWD` to unbreak .envrc access.

Unix "current working directory" at the kernel level is always the
absolute path (the process state tracks the VFS node, roughly).

Given this directory, file, and symlink:

    ~/foo/src/github.com/example/work-repo/
    ~/foo/.envrc
    ~/foo/quick -> src/github.com/example/work-repo

then after `cd ~/foo/quick` the fact that "quick" was used is not in the
kernel state.  The shell knows it, so that it can handle `cd ..`
specially (instead of accessing the VFS's `..` entry).  POSIX specifies
handling for `$PWD` (but doesn't require that the shell export it).
Typically, bash/zsh do export `$PWD`.  If, within `~/foo/quick/` you run
`bash -c pwd; env PWD= bash -c pwd` then you can see how `$PWD` controls
"what is the current directory".

The Golang `os.Getwd()` call looks at `$PWD` from environ, tries to
validate if it's correct for current process state, and if so returns
that potentially shortened (or lengthened!) pathname.

After `cd ~/foo/quick` the direnv logic for finding `.envrc` has walked
up the real FS and found `../../../../.envrc`, but when constructing a
filename tries to joing that to `$HOME/foo/quick` and then the functions
in stdlib can't find that.

Because I can't see any way that the symlinks affect what the correct
behavior of direnv should be, this one-line change just forcibly unsets
`$PWD` from environ at start-up.  This unbreaks stdlib.

This could conceivably be a security bug-fix, if the layout resulted in
stdlib succeeding in accessing the wrong, unverified/unvalidated .envrc
file.

direnv/direnv,direnv/direnv