NarSystemMojo: avoid using Iterator in favor of foreach loop

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix indentation of generated NarSystem class

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Teach NarProperties to extract a list of all known AOLs

In the upcoming support for using native-lib-loader to unpack and load
our native libraries, we will need to stay platform-independent. Hence
we will need to know what native libraries are bundled for the current
architecture/OS. Unfortunately, this is not enough information because
NAR uses a full AOL identifier (in particular, the linker name) to
identify the location of the native library in the .nar file. To remedy
this, we will simply look in the paths corresponding to all AOLs
matching the current "AO".

Side note: using properties.keySet() does *not* work in NarProperties
because the properties are usually empty. The properties inherit their
defaults from an opaque Properties object passed to the constructor, hence
the keys we are after are only available via the propertyNames() method.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
NarSystemMojo: use native-lib-loader when it is a dependency

When the native-lib-loader (https://github.com/scijava/native-lib-loader,
a library for unpacking and loading native libraries conveniently) is
among the dependencies, we should make use of it.

The current version of native-lib-loader (2.0.2) unfortunately expects
the native library to be bundled in a non-standard place, hence we have
to copy the library there.

To support the file layout produced by the NAR plugin, this uses
DefaultJniExtractor#extractJni directly instead of handing off to
NativeLibraryUtil (which would expect the bundled native libraries
in a different path).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an integration test for the native-lib-loader support

The native-lib-loader library is an incredibly useful thing to have when
working with native libraries: it unpacks bundled native libraries and
loads them. To make sure that our support for that library is not broken,
here is an integration test, to be run by our faithful Joyce Jenkins.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
it0026: verify that native-lib-loader works also with .jar files

So far, we only tested whether the NarSystem generated in the presence
of the native-lib-loader dependency worked with *unpacked* classes.
However, the whole point of the exercise was to support bundled classes
and bundled native libraries.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Rename it0026 to reflect the name of native-lib-loader precisely

The dependency we are special-casing is called native-lib-loader, not
native-library-loader. Let's avoid confusion and use the correct name
consistently.

This issue was noticed when this developer was puzzled why

	mvn -Dinvoker.test=it0026-native-lib-loader

would not Do The Right Thing ;-)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Better "Windows" OS compatibility in native-lib-loader context.

In Windows case, operating systems are started-with "Windows *". Instead of using ao.equals(), ao.startsWith() is suitable for deciding OS types in such a case.
Add native-lib-loader case in [narSystemPackage] in configuration.apt

Loading multiple native libraries are supported with help of native-lib-loader.
The short description is added in [narSystemPackage] section.
FAQ: Add a native-lib-loader case for multiple platform support

Provide an example how to use native-lib-loader for multiple platforms.
It is about how to use nar packaging.
Example: Add it0026-native-lib-loader

Provide an integration-test to use native-lib-loader.
Usage: Add "Create a JNI Library using native-lib-loader"

Provide code snippets to use native-lib-loader in pom.xml.
Merge pull request #129 from hkmoon/master

native-lib-loader option instead of using narSystem.