msvc build broken for ecpg

The recent ecpg commit seems to have broken MSVC builds:


descriptor.obj : error LNK2019: unresolved external symbol _pg_snprintf 
referenced in function _ECPGget_desc
error.obj : error LNK2001: unresolved external symbol _pg_snprintf
misc.obj : error LNK2001: unresolved external symbol _pg_snprintf
path.obj : error LNK2001: unresolved external symbol _pg_snprintf
error.obj : error LNK2019: unresolved external symbol _pg_fprintf 
referenced in function _sqlprint
misc.obj : error LNK2001: unresolved external symbol _pg_fprintf
path.obj : error LNK2001: unresolved external symbol _pg_fprintf
execute.obj : error LNK2019: unresolved external symbol _pg_sprintf 
referenced in function _ECPGis_type_an_array
execute.obj : error LNK2019: unresolved external symbol _pg_printf 
referenced in function _ECPGexecute
misc.obj : error LNK2019: unresolved external symbol _pg_vfprintf 
referenced in function _ECPGlog
path.obj : error LNK2019: unresolved external symbol _strlcpy referenced 
in function _join_path_components
thread.obj : error LNK2001: unresolved external symbol _strlcpy
.\Debug\libecpg\libecpg.dll : fatal error LNK1120: 6 unresolved externals   10 Warning(s)   13 Error(s)


This makes me worry about how fragile the support for MSVC is. If it 
can't handle changes like this then we'll forever be breaking things. 
That was one of the main reasons we went with MinGW/Msys in the first 
place - namely that we'd be using a single build system across all 
platforms.

This is not to say that the current build infrastructure is ideal - in 
fact I think it's pretty creaky. But I don't think we can accept an 
additional system which is always in danger of being out of sync.

Perhaps Magnus could give some precise details about the requirements of 
the buildsystem he's constructed.


cheers

andrew