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