On my self-hosted Windows runners, the `git`, `ssh-agent`, and `ssh-add`
commands are not located in the locations that are currently hard-coded
in `paths.js`.
With this PR, I am able to get this action to work on my runners as
follows:
```yaml
- uses: webfactory/ssh-agent@...
with:
ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}
git-cmd: git
ssh-agent-cmd: ssh-agent
ssh-add-cmd: ssh-add
```
### Problem:
Observed error on `windows-2022` ([GitHub-hosted runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources)) that `git` command cannot be found.
### Issue:
Cannot find git executable on on windows-2022 (GitHub-hosted runner) #136
### Solution:
This path improvement makes use of existing `path.js` to resolve and return correct `git.exe` path for Windows, leaving the executable name as it was for other operating systems.
### Caveats:
No idea how and why this `c://progra~1//git//usr//bin//git.exe` mumbo-jumbo works but it apparently did for other executables so figured it should work for `git.exe` (and it does).
execSync just started a second ssh-agent. `['-k']` argument was
treated as options, it didn't have `stdio` set, so stdio was piped and
returned (and ignored).
Thanks to @thommyhh for this contribution!
Unless the `SSH_AUTH_SOCK` is configured explicitly, this change will make the SSH agent use a random file name for the socket. That way, multiple, concurrent SSH agents can be used on non-ephemeral, self-hosted runners.
A new post-action step will automatically clean up the running agent at the end of a job.
Be aware of the possible security implications: Two jobs running on the same runner might be able to access each other's socket and thus access repositories and/or hosts.
