fix win32 with Ming.org GCC 3.4.5 build

fix win32 with Ming.org GCC 3.4.5 build

dlltool 2.20.51.20100123 from Strawberry 5.12 and
dlltool 2.17.50 20060824 from Strawberry 5.8.9 were making a libperl527.a
that caused perl.exe and all XS DLLs to import "perl527.exp.dll" while
the disk file is called perl527.dll.

This bug was eventually fixed, since in my testing dlltool 2.25 no date
code, Copyright 2014 from Strawberry 5.22.1 doesn't have this problem. I
suspect the bug was fixed in binutils commit 04276a0cf5
"2010-12-01 Kai Tietz <kai.tietz@onevision.com>"
https://sourceware.org/bugzilla/show_bug.cgi?id=11065
in version "AM_INIT_AUTOMAKE(bfd, 2.21.51)" or 1 ver bump higher. Just
always pass an explicit DLL name to dlltool instead of any kind of
dlltool version checking at build time and then optional arg.

The breakage for Mingw.org 3.4.5 was introduced in
commit bf543eaf90d "add parallelness to win32/GNUmakefile" where I added
parallelness by making the import lib .a file from just perldll.def,
rather than the import lib being a build product coming out of g++
linking perl527.dll. The old serial build recipie passed --dllname
to dlltool, my newer code didn't.

Passing $(PERLDLL) to dlltool's -D causes this harmless but scary warning

"dlltool: Path components stripped from dllname, '..\perl527.dll'."

So create PERLDLLBASE to silence the warning.

win32.h: In old GCCs,
https://sourceforge.net/p/mingw/mailman/message/22184185/ a function marked
declspec(dllimport) is not a constant. VC from day 1, and newer GCCs use
the address of a 1 instruction jump stub function if a constant function
pointer is needed to a function from a DLL that wont be known till runtime.
This can be worked around in older GCCs by deoptimizing them to always
use the jump stub for all references, and not the newer GCC and VC way
where x86 call instructions directly read the import table in the caller,
while constant functions ptrs in data or vars always refer to the jump
stubs. Since these are old GCCs, performance isn't the highest priority
and building at all is a more important goal. I suspect gcc 3.4.5 has
been broken since 5.13.6 when the declspec(dllimport) code was added.