Don't hard code git-crypt path in .git/config (even when invoked with absolute path)

When initializing a repository with `git crypt init`, the current behavior is to try to resolve the full path to the executable and save a section in the config such as:

```ini
[filter "git-crypt"]
smudge = \"/usr/bin/git-crypt\" smudge
clean = \"/usr/bin/git-crypt\" clean
required = true
```

This is baloney and needs to stop, at least on Unix. Well intention baloney maybe, but it takes over too much control from the host system. Resolving this path once on init makes the repository unportable. It turns out Unix system at least are really good at resolving paths and this is something that should happen at run time, not repo init time.

The offending function is `our_exe_path()`. I don't know about the Windows implementation, but on the Unix side of things this just makes life hard because the answer it comes up with only matches the system that initialized the repo, not the one that may be using it.

I have several repos that live on external disks or network drives and a large variety of systems that access them. The `/usr/bin/git-crypt` location is *pretty common but not universal* across them. Some are in `/usr/local/bin/git-crypt`, others such as CI runners often have `$HOME/bin/git-crypt` or similar user/project relative paths.

The way `git-annex` handles this makes repositories much more portable:

```ini
[filter "annex"]
smudge = git-annex smudge -- %f
clean = git-annex smudge --clean -- %f
```

Note the lack of path resoolution here leaving **the system** to resolve the path at run time.

I believe `git-crypt` would be better off doing the same thing.