Fixes to binary installer for windows proxies

* generateWindowsProxyCode() and generateUnixyProxyCode() now generate valid proxy code on ANY platform
* do not create extra unixy proxy code on windows if it's not needed (cygwin not found)
* now on windows exe installation works like: program.exe => program.bat, program.exe.bat
* windows proxy code now do not use "call" command to execute exe files, it solves problem with wrong arguments processing with "%" and "^" chars

Notes:
* extra shell wrappers for cygwin on windows break pattern: add ./vendor/bin in PATH and run application by short name like "application". The problem is by default windows try to run "application.exe" when you type "application" and windows find shell wrapper which didn't work. Possible solutions: change PATEXT to search for ".bat" before ".exe" or just fix that in composer to do not create shell wrappers on windows if cygwin not found and it was done in this update. 
* Also, on windows, when we try to execute binary we can type "program" (which will run "program.exe") or program.exe (which will run "program.exe". The same effect can be reached if we will create two batch wrappers for each executable: when we run "program" system will run "program.bat" (if  "program.exe" not found) and when we run "program.exe" system will run "program.exe.bat" (if  "program.exe" not found). Currently composer creates only "program.exe.bat" batch wrapper and in this commit implemented also creation of "program.bat" wrapper for ".exe" files.
* Also current implementation of windows batch wrapper contains defect: "call application.exe %*" is not applicable because application.exe will get all arguments escaped for passing to BATCH file! What side effects? Can't pass "%" and "^" in normal way. So the fix is to use "call" only for batch files and just run for all other cases.
* Also, generateWindowsProxyCode() and generateUnixyProxyCode() depends on host OS, because escape method depends. In this commit it was fixed and methods generate the same results on any platform. It will help in future to create cross platform wrappers for binaries running composer on any platform.
your assumption that this does not depend on the OS is wrong. ``escapeshellarg`` is **also** different based on the OS running PHP (but it is broken for complex cases on Windows, which is why a workaround is applied to escape in a safe way, which should not be removed)