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).

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".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use new BuildContext to support Eclipse better

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>
squash! Force m2e to execute most goals (non-incrementally)

[Mention that some goals will be executed also on configuration]
squash! NarSystemMojo: use native-lib-loader when it is a dependency

[Work in progress: needs to subclass DefaultJniExtractor and use it
directly instead of handing off to NativeLibraryUtil]