XD-2402 added spring-xd-starter-module starter POM

This adds a project to build a spring-xd-starter-module POM for module developers. For example to build a standalone module using Spring Integration Java DSL:

````
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.acme</groupId>
	<artifactId>siDslModule</artifactId>
	<parent>
		<groupId>org.springframework.xd</groupId>
		<artifactId>spring-xd-starter-module</artifactId>
		<version>1.1.0.BUILD-SNAPSHOT</version>
	</parent>
	<dependencies>
		<dependency>
			<groupId>org.springframework.integration</groupId>
			<artifactId>spring-integration-java-dsl</artifactId>
			<version>1.0.0.RELEASE</version>
			<exclusions>
				<!-- Still needed because it brings in the wrong version -->
				<exclusion>
					<groupId>org.springframework</groupId>
					<artifactId>spring-messaging</artifactId>
				</exclusion>
			</exclusions>
		 </dependency>
	</dependencies>
</project>
````

* The xd project structure has a root spring-xd-starters directory, allowing for additional starter poms if necessary. This follows the spring-boot-starters project structure.
* The starter pom is generated using the gradle maven plugin. The module starter declares dependencies on spring-xd-dirt and spring-xd-module-spi which give the plugin access to all of the transitive dirt dependencies. These are excluded in the boot-maven-plugin configuration which means that no xd runtime dependencies can be exported by the module uber jar. This avoids known issues due to version conflicts related to spring, jackson, tomcat, etc. without the module developer having to explicitly exclude such dependencies. This approach is perhaps too aggressive, since it encompasses dirt's wide-reaching transitive closure.  I don't believe there is an easy way to override these exclusions in case where a different version is needed for a module. A "smarter" approach is possible, e.g, the build can specify groups or artifacts which must be excluded, but it's not clear where to draw the line. 
* Note in the example above, excluding spring-messaging is required for building the module project, since SI java DSL happens to depends an older version than XD, causing single node tests to fail. This exclusion has no effect on uber jar packaging, since spring-messaging as already excluded in the starter pom.