Yasm r1713 fixed; building and Windows-native

The bug in Yasm r1712 was fixed this weekend (a side-effect problem  
caused by using a macro as a function).  Yasm r1713 tests perfectly.

I started modifying the build settings under configure.ac, etc. and  
looking at the mingw32_blah_blah (mingw32_HOST_OS and  
mingw32_TARGET_OS) defines in the rest of the system.  As you would  
expect, there are few areas where mingw32-conditional  HOST settings  
really overlap the TARGET settings, notably code in /compiler/cmm/ 
CLabel.hs and compiler/nativeGen/PositionIndependentCode.hs.

Ian: do you think some of the problems with the cygwin build might be  
related to this line in compiler/cmm/CLabel.hs:584 (labelDynamic):
	#if mingw32_TARGET_OS
	   ForeignLabel _ _ d  -> d
	#else
that is, labelDynamic might give false positives for dynamic code on  
cygwin?

I honestly don't have enough experience with DLLs and windows- 
libraries yet to start that porting task, but it seems like getting  
GHC to build a windows-native version means working out the Windows- 
compatibility problems at the same time or prior to the build system  
settings.   If you (or anyone else interested in a Windows-native  
port) would have time to take a general look at potential Windows- 
compatibility problems, I would be glad for the help.

As for basic modifications to the current build system, in addition  
to tracking $TargetPlatform in build.mk, I corrected a few  
assumptions (generally $host=$target) in configure.ac, so a user  
could call:

./configure --target=i386-unknown-windows

and still get the proper result.  I also had to conditionally change  
the assumptions that $Target..._CPP = $Host..._CPP.

As a general procedure, I would personally rather solve all Windows- 
compatibility problems first, then redo the build system to use SCons  
or some other Windows-native system and go from there.

Cheers,
Pete