Ray Donnelly authored Dec 30, 2015 and Christoph Reiter committed Jun 20, 2018

Revert "Windows port: Work arount MSYS weirdness where it changes --libtool= command line arguments."

A very old version of MSYS performed normalization during path conversion
so "/bin/sh ../../libtool" became "c:/opt/msys/1.0/bin/libtool" ("sh .."
was considered a single folder), it doesn't do this any more; nor does
MSYS2.

Also, the old comment was incorrect. It claimed:
"This continues to reuse the LIBTOOL variable from automake if it's set,
but works around some MSYS weirdness: When running g-ir-scanner, MSYS
changes a command-line argument --libtool="/bin/sh ../../libtool" into
--libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path
because we already "know" where the libtool configure produced is."

.. yet the actual code was changed to:
_gir_libtool = $(if $(findstring MINGW,$(shell uname -s)),--libtool="$(top_builddir)/libtool",$(if $(LIBTOOL),--libtool="$(LIBTOOL)"))

.. so in fact, if $(uname -s) contained "MINGW", then --libtool ignored
the LIBTOOL variable from automake and used $(top_builddir)/libtool
instead, at the very least, removing all trace of $(SHELL) from it.

Now that $(SHELL) has been re-introduced into libtool, it must not
doubly appear in resolve_windows_libs in ccompiler.py, as otherwise
sh.exe will try to execute sh.exe and that clearly will not work.

I've left some MSYS-specific hacks in dumper.py, some of which could
probaly be removed safely now (execution through a temporary shell
script), but I've opted to leave it as is for now.

This reverts commit 33bbdce1.