Include the Win32 extension in the ALL_STATIC build on Win32

Include the Win32 extension in the ALL_STATIC build on Win32

Many of Win32's Perl level functions are pre-defined (even without a "use
Win32" statement), while the implementation is in a dynamically linked
module. This is done via the statically linked Win32CORE wrapper that will
load Win32 on demand. The initialization of Win32CORE (init_Win32CORE()) is
called -- dynamically, via GetProcAddress(), since miniperl.exe doesn't
include it -- from Perl_init_os_extras() and normally relies on the DLL's
HANDLE having been set in the DLL_PROCESS_ATTACH case of DllMain() in
perllib.c. We must use a different HANDLE when the functions are located in
perl-static.exe since DllMain() is not called in that case, and, in fact,
it is sensible to consider other parts of DllMain() which
Perl_init_os_extras() might also need to do...

The #ifdef DEFAULT_BINMODE section can be scrapped completely since the
symbol is not defined, never mentioned anywhere else and not documented.
The DisableThreadLibraryCalls() call is not applicable for code that
doesn't reside in a DLL. That just leaves set_w32_module_name(), but that
is not required either, and may actually be redundant in the DllMain() case
too (maybe I will remove it later).

The last-but-one thing to do is to arrange for init_Win32CORE to be
exported from perl-static.exe (as it already is from perl519.dll, courtesy
of makedef.pl) otherwise GetProcAddress() won't find it. I see no harm in
always specifying __declspec(dllexport) in Win32CORE.c (except in one
existing Cygwin case which doesn't want it, which I'm not touching to
minimize regression risk). I thought that the .def file entry written by
makedef.pl for perl519.dll would then become redundant, and whilst the VC++
build worked fine without it, the MinGW build didn't: init_Win32CORE no
longer got exported from perl519.dll, thus breaking the normal build, so
I've therefore left makedef.pl alone.

The very last thing to do in some future change is to improve the
ALL_STATIC build so that Win32 functions like CopyFile() do not go
through Win32CORE's w32_CORE_all forwarding function as they currently do:
it isn't necessary when Win32 is statically linked as well! I will revisit
this part very soon...

Thanks to Jan Dubois and all the others in the following thread for
invaluable assistance in this and other recent changes in this area:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2013-06/msg00016.html