new driver search rules for WIN32 platform

[dzibarev@…]

It would be nice if both OGRSFDriverRegistrar::AutoLoadDrivers() and
GDALDriverManager::AutoLoadDrivers() searches for modules in current directory
when no GDAL_DRIVER_PATH or OGR_DRIVER_PATH environment variables are set.

[dzibarev@…]

Proposed solution for GDALDrivermanager

[dzibarev@…]

Proposed solution for OGRSFDriverRegistrar

[warmerdam]

Denis, 

Thanks for the suggestion, but I'm not really comfortable with doing this. 
I am concerned about accidentally trying to load DLLs/shared libraries with 
names prefixed with "gdal_*" as well as getting different results depending
on what directory is the current working directory.

But thanks for the feedback!

Best regards,

[dzibarev@…]

Another solution - look into executable module directory when searching for modules

[dzibarev@…]

Proposed solution

[warmerdam]

Well, this retains the fundamental problem of likely collections with DLLs
not intended to be plugins.  I would be willing to accept that this
seems somewhat
unlikely except that another use (Maciek) has already complained to me quite
severely about using insufficiently specific plugin directories, and because it
happens that my own FWTools distribution puts "gdal_fw.dll" in the
same directory
as the GDAL executables, even though this is not a plugin.

What about if GDAL looked in a gdalplugins directory under the
directory containing
the executables as a fallback?  So anyone wanting to provide GDAL plugin
drivers on win32 could just drop them in such a subdirectory under the directory
where the .exe files are?

[dzibarev@…]

Another patch.

[warmerdam]

I have applied a variation on this patch which accomplishes the same effect
in CVS.  The main difference is puting the GetModuleFilename() call into 
gdal/port so I can avoid pulling windows.h into mainly GDAL modules. 

I did a brief test on windows and it seems to work properly.

Thanks!