Incorrect plugin search when registering GDAL drivers

[mbrudka@…]

This bug is related with void GDALDriverManager::AutoLoadDrivers() method. The way this 
method works leads to errors, which manifest under windows, though it is possible other systems 
are also affected.
Method GDALDriverManager::AutoLoadDrivers() tries to load every file found in papszSearchPath 
starting with gdal_. For GDAL_DRIVER_PATH defined this is quite resonable. However when 
GDAL_DRIVER_PATH is undefined, method tries to load files from /usr/local/lib path, which is 
frequently used for storing other import libraries. Obviously, loading import library as shared one 
results in linking errors. To fix this bug, GDALDriverManager::AutoLoadDrivers() method should 
check if given file is  shared library before loading.
The current plugin loading is rather badly designed. I propose to change the functionality of 
GDALDriverManager::AutoLoadDrivers() as follows:
1. AutoLoadDrives should be parameterized be a search path.
2. GDAL_DRIVER_PATH should not be defined at gdal library level, but rather at the user 
application one. Every environment variable introduces configuration and deployment problems, 
hence they should be avoided. Otherwise configuration of the application becomes a nightmare.
3. RegisterAllDrivers should be parameterized by a search path, possible with NULL default.
4. Every file processed by GDALDriverManager::AutoLoadDrivers() should be verified if it is real 
shared library.
5. Every shared library should be check against compilation variant. Loading dll compiled in 
Debug mode in release version of the library often leads to critical errors. As a rule of thumb, one 
should never mix Debug and Release variants under Windows. (this is hard issue).

[warmerdam]

some discussion of the various issues raised occured on -dev list.  I'm not
willing to act on some of them.  I have made the following changes:

 o by default I search /usr/local/lib/gdalplugins. 
 o I now only try to load files ending in .so, .dll or .dylib. 
 o Added AutoLoadDrivers support on the OGRSFDriverRegistrar side.

this doesn't really resolve all of Mareks concerns but it should help.