Remove load library calls

The main idea behind this PR is to avoid calls to System.loadLibrary()

(This one was by mistake originally opened onto the fork from boundlessgeo, I apologize for the noise)

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 this 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. Duplicating the webapp (so that we can have several contexts trying to use the same native lib) shows that the second one is also unable to access the features that GDAL provides.

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).
@jericks in my opinion, providing the gdal.jar as a dependency is causing several concerns:

These bindings are linked to a specific gdal/ogr compilation. Thus, it requires the developer to use the underlying versions of the native libraries (which can come with software that can lead to licensing issues - ECW for instance), while he could use another one (e.g. one provided by the OS). In the next Debian version for instance, gdal.jar is provided as a package (libgdal-java), which is compatible with the native gdal lib provided by the official libgdal package.

Using mismatched jars & native libraries can lead to inconsistencies in the java applications, even if the JVM is able to resolve the classes and the JNI library (see this comment: http://stackoverflow.com/questions/16539921/java-lang-unsatisfiedlinkerror-using-jni#comment23785880_16539921)

This is the reason why, in our application, we explicitly excluded this jar from our dependencies at a webapp level, tackling the problem of class resolving "higher" into tomcat using the shared classloader, so that:

1. we can choose a gdal.jar which is compatible with the native libgdal we point into our `JAVA_LIBRARY_PATH`, and for which we have the choice to include or not some proprietary addons, as well as we are free to select whatever version of gdal we want ;

2. We can share the gdal.jar across the different classloaders, resolving the first concern of this PR (being able to use GDAL/OGR with GeoTools across several classloaders).