Avoid calls to System.loadLibrary()

In some special but common cases, several different calls to
System.loadLibrary using the same lib name as argument can lead to
undesired behaviours (Raising an exception
"java.lang.UnsatisfiedLinkError: library already loaded in classloader").

A typical case of specific classloading is when using the library in
several different webapps nested into the same servlet container
(tomcat). Even if the library is actually correctly configured and fully
available, GeoTools reports it as unavailable (due to the exception
thrown).

A PoC which tends to prove this issue has been provided here:
https://github.com/pmauduit/jai-imageio-sample/tree/master/jai-imageio-gdal-sample-webapp

In the PoC webapp, a first approach makes use of the JNI GDAL/OGR
bindings directly, another one is then attempted using GeoTools (class
JniOGRDataStoreFactory). The first one (once tomcat is correctly
configured) shows that the library is fully available, though it is
reported as unavailable by GeoTools.

The litterature I could read on the topic (classloading in Java seems to
be one of the big mistery around the language, though) explains that we
should avoid packaging webapps with jar files making use of the
System.loadLibrary calls. These have to be shared: the jar file should
be made available in the higher-level classloader (for tomcat under
debian-like distros with libgdal-java installed, it means having a
symlink from ${CATALINA_HOME}/lib/gdal.jar pointing to
/usr/share/java/gdal.jar).

Note: There are several other calls to System.loadLibrary(), but they
are made from the ImageIO-Ext code, and then should be fixed there.