Commit introduces a prototype of the Maven plugin which is able to
apply Eclipse formatter step to all java files in the project. It
only takes a single parameter - 'eclipseFormatFile' which is a path
to the formatter configuration.

Maven plugin is build and packaged using Maven which is executed from
the Gradle build script via Exec plugin. This seems to be the simplest
way to get a JAR with "maven-plugin" packaging. Gradle does not have
a native plugin to do this.

This change just adds a bare minimum to verify the approach.

Exposed `encoding` and `lineEndings` in the plugin xml configuration.
Renamed `eclipseFormatFile` to `eclipseConfigFile` and moved it inside
the `<java>` tag. Maven plugins can handle nested configs using Plexus
dependency injection and POJO objects. Thus introduced a dedicated
class for all java related configuration called `Java`.

Plugin xml configuration can now look like:

```
<plugin>
  <groupId>com.diffplug.spotless</groupId>
  <artifactId>spotless-maven-plugin</artifactId>
  <version>${spotless.version}</version>
  <configuration>
    <encoding>UTF-8</encoding>
    <lineEndings>UNIX</lineEndings>
    <java>
      <eclipseConfigFile>${basedir}/eclipse-fmt.xml</eclipseConfigFile>
    </java>
  </configuration>
</plugin>
```

Extracted an abstract `AbstractSpotlessMojo` to hold all injected
dependencies. It can be potentially used in future to implement
the `check` goal.

Changed name of `SpotlessMojo` from "spotless" to "apply" so that
it can be invoked with `mvn spotless:apply`.

Injected `MavenProject` is now replaced by injection of multiple
primitive values, like `project.basedir`.

Removed shading & local repository for `lib` and `lib-extra`. Instead
made plugin directly depend on stable version denoted
by `project.stableLib`.

Made all maven plugin API dependencies provided and their versions
injected by the Gradle build script.

These don't match the current implementation exactly, but
I think they're close.  I don't know much about maven, lets
get the docs right, and then build to the docs.

Gradle build script will now use Mustache template to create pom.xml
with needed versions. This should be more reliable and future-proof
than previously used `String#replace()`.

Restructured code to better support addition of new formatter steps and
formatters. Spotless mojo now accepts java configuration with list of
steps. It is also possible to specify global encoding, line endings
and override them for java.

New `pom.xml` config looks like:

```
<configuration>
  <encoding>UTF-8</encoding>
  <lineEndings>UNIX</lineEndings>

  <java>
    <encoding>US-ASCII</encoding>
    <lineEndings>WINDOWS</lineEndings>
    <steps>
      <eclipse>
        <file>${basedir}/build/eclipse-format.xml</file>
        <version>4.7.1</version>
      </eclipse>
    </steps>
  </java>
</configuration>
```

…older location as 'plugin-maven'.

Gradle build script creates builds spotless maven plugin by shelling
out to maven. It then installs the plugin JAR into a local maven repo
that's later used for tests. Task "test" depends on all these steps.
Maven integration tests generate pom.xml based on a template. This
pom references the previously created local maven repo to locate
spotless plugin. Tests then invoke maven via Process API and compare
formatter with unformatted files.

Make test task print assertion failures.

In maven plugin integration tests. Previous assertion on string
obtained from stderr failed on CI. There build agents print
"Picked up _JAVA_OPTIONS: -Xmx2048m -Xms512m" to stderr when
java is launched.

So that it is able to depend on snapshot version of lib and lib-extra.
All compile dependencies with transitives are now installed into local
maven repo. This repo is used both for building and testing the plugin.

Previously it only resolved given coordinates to a single artifact.

To make goal `spotless:check` accessible. Moved all functionality
common for "apply" and "check" into `AbstractSpotlessMojo`. Now command
`mvn spotless:check` will result in all formatting violations being
printed and build being failed.

…ady.

…has up-to-date checking.

…blishing works automatically.

Split configuration into two - one for `FormatterFactory` and other
for `FormatterStepFactory`.

Previously each `FormatterFactory` had to return only a single
extension. This worked fine for Java but does not hold for other
languages, like Scala.

Maven by default allows only a single compile root dir. Plugins can
add more or override at runtime but by default it's only
`src/main/java`. When single plugin goal, like `spotless:check`
is executed this single source root is what it can access.

Previously spotless mojo scanned only compile source roots. This made
it only see java files. It wasn't able to see for example scala files
that usually live at `src/main/scala`. This happened because
`src/main/scala` source root can be added by other plugins (like
scala-maven-plugin http://davidb.github.io/scala-maven-plugin/add-source-mojo.html)
and such plugins are not executed when single spotless mojo is invoked.

This commit makes spotless mojo start scanning files from project root
directory. It will only skip `target` directory right now.

It allows scalafmt version and configuration file to be configured.

They were previously not executed because of missing `@Test`
annotation. When enabled, they failed because maven was not able to
find `LicenseHeader` implementation. Looks like Maven is only able
to locate classes for injection when they live in the same package
or in subpackages of the current package. For example step `Java`
lives in package `com.diffplug.spotless.maven.java` and to be able
to inject implementation of `licenseHeader` step it should also live
in `com.diffplug.spotless.maven.java` or any of it's subpackages,
like `com.diffplug.spotless.maven.java.hello`.

This commit makes generic license header an abstract class and adds
implementor for Java in the correct package. Such implementations
are now also responsible for default delimiter. This feels cleaner
than putting delimiter in `FormatterFactory` implementations.

They do not keep any internal state. Every field is injected by Maven.

And need to restructure packages. Turns out Maven (underlying Eclipse
sisu container) requires injected classes be in the same package as
the class that's being configured. That's only in case of direct field
injection. With setter/adder is class can be in any package because it's
`Class` will be determined based on the type of setter/adder parameter.
It is also guaraneteed that setters and adders will be invoked in the
order of corresponding xml elements. This removes the need for `<steps>`
and makes it possible to place classes in nice packages. One drawback is
that explicit adder methods are required. At the same time they provide
an ability to explicitly define which steps are supported for the given
formatter. This makes error messages a bit prettier when for example
"googleJavaFormat" is configured for Scala.

Eclipse sisu doc for adder/setter:
https://www.eclipse.org/sisu/docs/api/org.eclipse.sisu.plexus/reference/org/eclipse/sisu/plexus/CompositeBeanHelper.html

Property is `spotless.check.skip` and takes a boolean value. Can either
be specified in POM `<properties>` section or in command like like
`-Dspotless.check.skip=true`.

It will be shown as MOJO description.

Which makes `<phase>verify</phase>` unneeded in plugin execution
configuration. Example to bing 'check' to verify phase:

```
<plugin>
  <groupId>com.diffplug.spotless</groupId>
    <artifactId>spotless-maven-plugin</artifactId>
    <version>${spotless.version}</version>
    <executions>
      <execution>
        <id>check</id>
        <!-- <phase>verify</phase> --> <!-- no need for this line -->
        <goals>
          <goal>check</goal>
        </goals>
      </execution>
    </executions>
 </plugin>
```

Maven wrapper makes it easy to control version of maven and
it's installation. Version can be changed in
`.mvn/wrapper/maven-wrapper.properties` file.

Everything in src/main/resources will get shipped to users inside the jar.  No need to ship mvnw.  Also appears that some of the plugin installation tasks might be failing on the buildserver, perhaps because the install tasks didn't depend on copyMvnw.

This reverts commit a676bc4.

…ettings.xml.

For tests only.

It is not needed because maven plugin and tests specify custom
local repository via `-Dmaven.repo.local` system property.

….spotless group before caching.

…r maven-install-plugin and the wrapper.

This commit makes it possible to configure includes and excludes for
paths/files with Ant style pattern in configuration groups (currently
Java and Scala). It also changes the default source roots for scanning.

Default policy for scanning used to recursively start from the `basedir`
and include files with needed extensions, like "*.java" or "*.scala".
This worked fine for simple maven projects but resulted in a lot of
extra work for multi-module maven projects. Same files had to be
scanned more than once during parent and then child module scanning.
Now scanning will use most common source roots for supported languages.
They are "scr/main/java/**/*.java", "scr/test/java/**/*.java" for Java
and "scr/main/scala/**/*.scala", "scr/main/scala/**/*.sc",
"scr/test/scala/**/*.scala", "scr/test/scala/**/*.sc" for Scala. So
only these common source roots will be scanned by default.

Mentioned patters form default includes. Default excludes are empty,
except output directory (usually "target"), temporary files and VCS
files are always skipped. It is possible to override includes and add
excludes. This can be done like this:

```
<java>
  <includes>
    <!-- include all java files in "java" folders under "src" -->
    <include>src/**/java/**/*.java</include>

    <!-- include all java files in "java" folders under "other" -->
    <include>other/java/**/*.java</include>
  </includes>

  <excludes>
    <!-- exclude examples from formatting -->
    <exclude>src/test/java/**/*Example.java</exclude>
  </excludes>
</java>
```

Similar configuration is possible for Scala. Custom includes completely
override default includes. Default excludes of output directory,
temporary and VCS files can't be overridden.

…l pom.

Generic formatting steps, like LicenseHeader can be defined both
globally and inside language configs. Example:

```
<configuration>
<!-- global license header config -->
<licenseHeader>...</licenseHeader>

<java>
  <!-- overridden license header for java -->
  <licenseHeader>...</licenseHeader>
</java>
</configuration>
```

Previously global config had no effect. This commit fixes the problem
by passing globally configured generic steps down to `FormatterFactory`
which creates steps and uses globally configured ones, unless
overridden.

License header is a generic step that is applicable to both `Java` and
`Scala`. This commit moves adder for it to `FormatterFactory`, which
is super class of both `Java` and `Scala`. Code duplication is thus a
bit reduced.