implip and export file erronously created when linking with GDAL on MSVC

[yakov]

When building an EXE project (not a DLL project) that links in the GDAL libraries on Visual Studio, an import library and export file are created. This is time-consuming - especially for large EXE projects, and happens due to wrong declarations inside GDAL header files.

Details about why it happens and how to fix it follow.

GDAL marks its classes for __declspec(dllexport) even in the executable that links against it. It manifests in that all its inline functions, including those of std::string, get compiled in and exported from our executables. This causes import libraries being created for our executables, a bloat of their *export* tables, binary sizes and compilation times.

Simply defining CPL_DLL to __declspec(dllimport) does not work because then it clashes with std::string members being "already deined in" both, GDAL import libs and our executables.

What should be done:

CPL_DLL shall be specified per each function, defined as dllexport when building GDAL and as dllimport when linking against it. The corresponding warnings resulting from using std::string members, arguments and return values in GDAL interface should be disabled, or the std::string shall be removed from the interface completely.