Sensitivity to the UNICODE flag when compiling under Win32

[Daniel Morissette]

This was initially reported as MITAB bug ​http://bugzilla.maptools.org/show_bug.cgi?id=1935 but since that's related to files in gdal/port used by MITAB I'm filing a ticket here to discuss the issue before any action is taken:

The key issue is that it is easy under Visual Studio to attempt a build with 
the UNICODE flag set and the Windows specific code is more sensitive to this 
than it needs to be.

The general issue is that functions such as LoadLibrary are actually 
conditional macros that are sensitive to the UNICODE flag and expand 
into either LoadLibraryA (for ASCII) or LoadLibraryW (for wide).  However,
since MITAB is not Unicode aware this makes the code fragile.

To make the code more robust, I suggest replacing the following calls.

* In cplgetsymbol.cpp replace LoadLibrary with LoadLibraryA

* In cpl_multiproc.cpp replace the two calls to CreateFile to CreateFileA

* In cpl_getexecpath.cpp replace the call to GetModuleFileName with
GetModuleFileNameA

I have made these changes on my local version and have a clean build even with
the UNICODE flag set.

[warmerdam]

Removing milestone.

[Even Rouault]

In 40838:

Windows builds: use explicit ANSI functions when needed (fixes #2545)