Work in progress patch for porting PostgreSQL to Windows x64

This patch makes almost no changes to PostgreSQL code; nearly all of it is to the MSVC build tools.  I had to learn Perl to do this, so it might be very poor code, stylistically.  I don't know.

New files: you'll see a very large number of +'s next to some of the diffs.  These are two new files: 

src/include/pg_config.h.win64
and
src/include/port/win64.h

I wondered if I should make these separate from pg_config.h.win32 and win32.h, because the API is the "Win32 API" whether it is on x86 or x64.  So they have a lot in common, and that might make things difficult for Windows maintainers.  But there are some changes I needed to make in both of them, so I just made two new files.  My reasoning is that as the years go on and more people get > 4 GB of memory, x64 will become the one and only "Windows" and x86 will disappear.  And during all that time they'll probably diverge more and more.  It is probably better to keep them separate right from the beginning.

pg_config.win64.h defines the macro DATA_MODEL_LLP64.  This will later be used to change a few of the PostgreSQL interals so that we may work with compilers where sizeof(int) = sizeof(long) = 4, but sizeof(size_t) = sizeof(void*) = 8, which is currently not allowed.  The name of this data model is LLP64 as opposed to LP64 which is assumed by PostgreSQL now: http://www.unix.org/version2/whatsnew/lp64_wp.html  Note that x86 Windows uses ILP32, which happens to be compatible with the ILP32/ILP64-based assumptions made by a lot of the postgres code.

Before this patch, the build script supported the Visual Studio 2005 32-bit compiler.  It now supports the Visual Studio 2008 32-bit compiler, and the 64-bit cross compiler for both versions.

I have observed a very significant problem on the Windows platform having to do with exported functions in libraries.  Some of the functions and global variables are exported using PGDLLIMPORT (a small number), while a much larger number are not.  The creator of the build script solved this by creating a Perl script which uses a Microsoft utility (dumpbin) to dump the symbol tables from the object files, then parse through the output to build an export definition (.def) file.  The x86 and x64 ABI's are different, so I modified the script to remove the x86 name decoration (x64 names are undecorated) in case the platform is x64.  One problem is that both of the MSVC x64 compilers do not like multiple definitions, even if the definitions match.  They would prefer either a .def file only or use __declspec(dllexport) (i.e., PGIMPORTDLL) exclusively, but not both.  Currently the patch uses both because they overlap sometimes, and surpresses the warnings messages.

Unfortunately there is no nice way to solve this.  The first option is putting PGDLLIMPORT in a TON of places.  In addition to being very irritating to actually do, it is ugly and I am sure this would inflame the anti-Microsoft sentiment so much as to not be possible.  However, there is something to be said for explicitly marking in code what needs to be made external and what does not (unless this is already the case, everything that does not is already marked static, and you actually do want all 5000-something symbols to be public).  On the other hand, the build script is dependent on a tool which is not documented very well, and is likely to change and then damage the parsing ability of the Perl script.  There is also the problem that uninitialized data in .bss segments has the same compressed dumpbin information as functions and data which actually are external.  Only PGDLLIMPORT can mark these for export using the current method (this is needed for SPI to work at all) since their compressed symbol table entry is ambigious.  The situation will probably change in the future, as x64 becomes more common all the special tools developers use will probably have a program to solve problems like this.  But the way it is right now seems very precarious to me; if the next version of the compiler does not somehow totally break the dependency system, I will be surprised.  A better way would be to get a list of the needed symbols directly from the GNU tools, since unlike the dumpbin, we have control over these.  Forgive my ignorance of the GNU toolchain, but how are these provided?  How are you building the shared libraries now?

In the next WIP patch, I will be working on making PostgreSQL compatible with LLP64 compilers.  Depending on how much work this is, I will post it as one or two WIP patches, because many of the changes will be to critical backend parts of the system.