Thanks for the merging advice!

The patch to the build system is indeed trivial - unfortunately it also
failed to work correctly due to install.c using freopen, a CRT function,
to redirect the output.  Interestingly, this probably means that if
someone attempted to use python 2.6 to create a pure-python .exe
installer, they would fail to see any output when installed to earlier
Python versions (and vice-versa...)

I've worked up a patch for install.c which uses the win32 API to achieve
the same result using SetStdHandle() etc.  This technique requires the
handles to be redirected before the Python DLL is loaded, so I took the
opportunity to refactor things a little - we now have 2 locations that
perform the redirection instead of 3 but I didn't see huge benefit in
trying to knock that down to 1.

The patch is against the trunk but should also be applied to 2.6 and the
3.x branches.  I've tested the new code-paths using a 32bit trunk build
only but it should work the same everywhere.