Workaround for the evil path-lookup discrepancy when invoking Git's sh

[xparq]

Well, there are two Git shs... Oh, wailt, three even, actually!... :-o And the "wrong" one is on the PATH here.

1. On the PATH, unusable here: "C:\Program Files\Git\usr\bin\sh.exe"
2. Not on the PATH, but the one we need: "C:\Program Files\Git\bin\sh.exe"
3. And I have 0 clue what exactly this one does differently, but unusable too: "C:\Program Files\Git\git-bash.exe"

Test:

set "GITROOT=C:\Program Files\Git"
where sh.exe
rem        -> C:\Program Files\Git\usr\bin\sh.exe
where find
rem        -> C:\Windows\System32\find.exe
rem        -> C:\Program Files\Git\usr\bin\find.exe
@echo.
@echo This will use Windows's find.exe:
sh.exe -c "which find; find . -name '*.*'"
@echo.
@echo This will use Git's find:
"%GITROOT%\bin\sh.exe" -c "which find; find . -name '*.*'"
@echo.
@echo WTF is this trying to do?
"%GITROOT%\git-bash.exe" -c "which find; find . -name '*.*'"

Also, critically: don't forget -c (the error message is horribly misleading)!

>"...\sh.exe" find -- version
find: find: cannot execute binary file

So:

sh -c "find --version"

[xparq]

OK, the checks have been tightened, and BB support extended a lot (-> #22), as of 599fd7d