added assertions, javadoc and make QA tools happy, no functional changes intended
Made LibraryLoader <package private>, because the class is not meant to be an API.
The class is relatively new, so I hope we don't break to many depending projects.
Merge branch 'development' into feature/jni-loader

Conflicts:
	rxtx-api/src/main/java/gnu/io/LibraryLoader.java
implemented JAR aware library loader

Until now, loading native JNI libraries was done by calling
System.loadLibrary() directly in the static initialisation
section of CommPortIdentifier. System.loadLibrary() expected an
appropriate library to be on the classpath (or library path).
This approach has two problems:

1) With the introduction of 64bit systems it was no longer
ensured that the correct library for the system was loaded.
This is because System.loadLibrary() does not care about the
architecture of the available libraries at all.
It distinguishes between them using some naming conventions
for different platforms only (e.g. libfoo.so vs. foo.dll).
This is not sufficient to distinguish between e.g. a
linux x86_64 and x86 library, because they have the same
file name. This led to some hacks experimenting with name
suffixes, weaken the code quality.

2) Because users were forced to set up the library path, the
usage of the API was more difficult then necessary.

To overcome these limitations a LibraryLoader was created, which
can load JNI libraries from a JAR file and other sources. The
loader distinguishes between architecture and platform using
well defined postfixed library names. The postfixed name of the
library correlates with the artifact directory.

e.g. librxtxSerial-linux-x86.so is called POSTFIXED whereas
librxtxSerial.so is called NON-POSTFIXED

There are three basic use cases:

I) Out of the Box (load from resource)
The user obtains the pre-packed default JAR distribution of RXTX
which contains the default drivers and their respective JNI
libraries for all supported (or chosen) platforms.

Whenever the LibraryLoader can find the JNI libraries for the
current platform inside of the JAR (or registered driver JARs
when using additional drivers) these will be extracted to a
temporary directory and being loaded.

II) Redistribution (load from classpath)
Because the extraction from JAR at every program startup, might
be performance critical, a developer of a program depending on
RXTX might decide to setup the libraries once (e.g. via some
installer). In this case the libraries must not be packed to the
JARs.

When the LibraryLoader detects the absence of a library in the
JAR, it falls back to load it from the classpath (or library
path).

III) OS level installation (load from system library path)
When RXTX (and RXTX driver implementations) are distributed via
a system package manager (e.g. apt-get on debian based platforms)
the LibraryLoader does not need to select the correct binary.
This is because the installation package will set up only the
correct binary matching the platform. This is assured by the
system package manager itself. In such a case the long postfix
as used with I and II might be redundant and confusing. Therefor
it can be ommitted by the packager.

When the LibraryLoader can not find a postfixed version of a
library in the corresponding JAR, nor on the classpath, it
will look for a non-postfixed version on the system library
path. An application as described in II should never expose
non-postfixed libraries in its classpath. This could lead to
an incompatible JNI contract.
LibLoader: fixed .jnilib/.dylib naming for OSX et al

Some operating systems allow multiple library naming conventions,
but the architecture of System.mapLibraryName() doesn't support
this behaviour.

On some os like mac OSX the default library mapping depends on the
JVM version, but on all JVMs both library variants can be actually
loaded. This fix ensures, that the correct naming convention is
used ("lib" + ".jnilib"), independent from the JVM version.
libLoader: fixed wrong logging message output
libLoader: using unique TempFile numbering

The LibraryLoader extracts library binaries to the default
temporary location. These files are marked with the
File.deleteOnExit() method and are deleted when the JVM
is shutting down. To prevent problems when more than
one JVM instance is running, this fix uses the
File.createTempFile() method to enable unique file naming
for the extracted binaries.
Merge branch 'feature/jni-loader' into development
removed parallel port support

The default serial and parallel port drivers of RXTX were both
implemented in the RXTXCommDriver class. This is against the
intention of the SPI, which suggests separate driver classes.

Because the current development focuses on the serial port driver
as a reference implementation of the SPI, the parallel port
support is completely removed.

The parallel port might be reimplemented as a separate driver
in the future.
Merge branch 'feature/remove-parallel' into development
upgraded JVM dependency to Java SE6
implemented driver discovery via ServiceLoader

Until now the instantiation of (the only available)
driver was hardcoded. Now the available CommDrivers
are discovered by the Java SE6 ServiceLoader mechanism.
This enables developers to plugin their own driver
implementations.

To control the discovery process the new class
DriverManager was introduced.

This patch changes functional backward compatibility
since the user is forced to call
DriverManager.loadDrivers() before any other interaction
with the API. This behaviour was introduced because
the old way to load the drivers from the static init
section of CommPortIdentifier, turned out to be
very test unfriendly. Additionally the time when
the drivers are initialized could not be controlled,
which results in bad responsiveness while the first
contact with the API.

This patch includes a test case for the new functionality.
update to use @Deprecated annotation

Due to the upgrade to Java SE6 in addition to the javadoc
tag "deprecated" the @Deprecated annotation is used.
Merge branch 'feature/service-loader' into development
cleanup logging and porting to java logger

A LOT of debug System.out.println() statements cluttered up the
code and made it difficult to read.

Abusing the default output with trace messages is concidered to
be bad style. The important error and trace messages were therefor
ported to use the java built in logging facility. Less important
messages were removed.

In addition the logger approach possipbly eases bug reporting,
because tracing is possible without recompiling the library.
Merge branch 'feature/logger' into development
RXTXCommDriver: refurbished property file/resource loading

Caused be the java dependency upgrade a foreach style loop
can be used, now. Important events are now logged.
RXTXPort: moved field declarations to top of file

The RXTXPort class mixed the order of method and field
declarations contrarily to the recommendation of the java
sun code style.
RXTXCommDriver: updated javadoc
RXTXPort: added review comment for possible dublicate