Setting a goal prefix 'autotools' for this plugin

Thus, you can now easily run e.g. 'mvn autotools:compile' instead of
the lengthy 'mvn net.sf.maven-autotools:maven-autotools-plugin:compile'.
Merge https://github.com/eyealike/maven-autotools

Conflicts:
	plugin/pom.xml
Removed private repositories and distribution management references

There were URLs in several pom.xml files, pointing to private
repositories and distribution management locations.  As this is
no longer supported (http://bit.ly/aIYD38) for the OSS central
repository, I decided to just remove them.
Added several copyright notices
Moved the 'pre-clean' execution to the appropriate lifecycle configuration

Running 'mvn clean' failed unless having built the plugin at least
once.  That happened due to an explicit invocation of the 'pre-clean'
goal in 'it/pom.xml'.  This is not necessary anymore, since I moved
the lifecycle declaration to 'META-INF/maven/lifecycles.xml'.
Fixed invocation of the 'configure' command

A missing '"' in the construction of the argument list lead to the
situation that the mojo parameter 'configureArgs' was basically without
effect.
Fixed an issue with post-processing the autoscan result

To give some background: When the maven-autotools-plugin doesn't
find a configure.{ac,in} file under src/main/autotools, it begins
with running the autoscan command to generate a preliminary template
instead, named 'configure.scan'.  After that, a script called
'autoscan-post' performs some minimal steps to turn that template
into a valid 'configure.ac'.

Prior to this commit, a simplistic sed script was used for post-
processing the 'configure.scan' template.  In some situations, the
autotools chain was run a second time, so that for example the
Makefile already existed.  Final post-processing then caused the
M4 macro call 'AC_CONFIG_FILES([Makefile])' to appear twice in
the 'configure.ac', which in turn caused the automake command to
fail.

Now the post-processing of the 'configure.scan' template is done
by a slightly more savvy awk script, which avoids inserting the
macro call repeatedly.
Enabled filtering for archetype resources

The archetype templates 'configure.ac' and 'Makefile.am' need variable
substitution for ${artifactId} and ${version}.
Improved and extended some unit tests

Additional test cases:

  - FileUtils.calculateRelativePath
  - autoscan

Testing the autoscan case required a new mojo parameter to specify the
filename postfix of the 'autoscan-post' script.  Otherwise it would have
been impossible to setup test expectations correctly.  The new mojo
parameter is called 'generatedScriptPostfix'.
Added the 'mingw' mojo parameter

This parameter indicates that the MinGW (http://www.mingw.org/) compiler
should be used rather than that of Cygwin.  It takes effect on Windows
only.
New utility methods to determine platform architecture and operating system

There are new methods like isWindows(), isMacOSX(), isLinux() to check
on which operating system the build is running, and methods like isPPC(),
isX86(), and isX86_64() to determine the processor architecture.
New mojo parameter 'platformMapping' for renaming platform names

In a887cba961 we changed the system names from 'i386' and 'amd64'
to 'x86' and 'x86_64' respectively.

The new parameter 'platformMapping' can be used to revert to the
previous names:

    <plugin>
        <groupId>net.sf.maven-autotools</groupId>
        <artifactId>maven-autotools-plugin</artifactId>
        <configuration>
            <platformMapping>
                <x86>i386</x86>
                <x86_64>amd64</x86_64>
            </platformMapping>
        </configuration>
    </plugin>
Improved loading of a native library in the archetype code

The archetype for a shared library now provides some code to determine
the system architecture and the operating system as well as the file
extender of shared libraries.  All this is necessary to load a native
library in the method 'loadNativeLibrary'.

It should be noted that there's some duplication of code originally
found in 4367d3e9d2.  Although this violates the DRY (don't repeat
yourself) principle, we refrain from introducing an additional
dependency in the archetype code.
Correct the final install location of DLLs on Windows

When running 'make install' on Cygwin, dynamic libraries get copied to
the 'bin' directory in contrast to other platforms, where these belong
to 'lib'.  This fix ensures, that Windows DLLs will go to the 'lib'
directory as well.
Copy macros to 'm4' directory instead of appending them to 'acinclude.m4'

There are several m4 macros bundled with the maven-autotools-plugin that
were formerly appended to 'acinclude.m4'.  Now we just copy those to the
'm4' directory.
Changed the project description and the README
Creating javadoc and source jars for deployment
Activated verbose logging for all integration tests
Updated unit tests to use JUnit4
Replace '@parameter' with the '@component' annotation in the Mojos

The '@parameter' annotation, which was formerly used to assign plexus
components to Mojo fields, has been marked as deprecated for that purpose.
Instead, we're using the recommended '@component' annotation now:

  @component role="..." roleHint="..."