bpo-2445: Allow the UnixCCompiler.find_library_file to correctly find DLL import libs (.dll.a) on Cygwin

[embray]

This is a fix/workaround to a rather old issue (https://bugs.python.org/issue2445) that still hasn't had a fix merged.

The original patch is by @ma8ma .

This simple patch allows UnixCCompiler.find_library_file, which searching library directories (e.g. /usr/lib), to recognize .dll.a as matches for the library. This is necessary on Cygwin where actual DLLs are not typically found under <prefix>/lib, but rather <prefix>/bin (because Windows searches PATH for DLLs). However one does .dll.a import libs under <prefix>/lib (these are simple static archives that contain stubs for symbols actually found in the DLL, which can be used in lieu of the DLL itself for linking). This satisfies that the library being searched for is typically found.

This is especially necessary now that the _ctypes module can only be built with --with-system-ffi; without this patch the system libffi cannot be found.

https://bugs.python.org/issue2445

[ma8ma]

FYI, https://bugs.python.org/issue4032 has a patch which changes to use UnixCCompiler lastingly on Cygwin. (probably, it cannot use as it is)

[embray]

That is maybe a better patch. This patch is a bit janky because it reuses the dylib_lib_extension variable which previously only had meaning on OSX, but is a bit of a misnomer for searching for DLL import libs. The patch from issue4032 actually adds a separate implib_lib_extension variable that is only meaningful on *nix-on-Windows platforms; particularly Cygwin, though it could also be considered meaningful on mingw and the like i think...

[ma8ma]

Yeah, I think so too. I submit the bpo-4032 patch after modify it.

[embray]

Closing in favor of #4153.