Force m2e to execute most goals (non-incrementally)

Eclipse's Maven integration requires certain extra steps of each Maven
plugin, to state how compatible the plugin is with Eclipse's version of
a lifecycle. With this change, we tell Eclipse to execute most NAR
goals, but only when building from scratch (because the steps are pretty
expensive).

Some of the goals are also triggered upon configuration, e.g. the
generation of a NarSystem class or downloading/unpacking dependencies.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
eclipse style fixed.
Let Eclipse know about generated NarSystem classes

According to http://wiki.eclipse.org/M2E_compatible_maven_plugins we
should use the BuildContext to inform Eclipse about updated and created
source files.

Happily, the BuildContext allows us to do that without having to link to
Eclipse proper, let alone having to write and deploy a full-blown Eclipse
plugin.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Merge pull request #130 from maven-nar/eclipse

Improve Eclipse support
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>