XD-1901 Fix Job undeploy

- Remove `basicUndeploy` from AbstractDeployer which deletes the deployments path
including the `status` node
  - This would allow `undeploy` method from AbstractInstancePersistingDeployer
takes care job undeploy from ZK job repository that transitions the state appropriately.
XD-1905 Added module name to log warning if no containers match criteria
XD-1915 Adding hadoop24 as supported distro
XD-1881 followup
XD-1895 - Upgrade to Boot 1.1.3 and use the Platform to provide versions

- This commit reapplies the changes originally made in 246ef90b and
updates publish-maven.gradle to import the Platform's bom for
dependency management in each of the published poms.
- Add snapshot repostitory to generated pom for platform snapshot
XD-1909: Update to Spring Shell 1.0 RC4
XD-1882: Added remote partitioning to the filejdbc OOTB job

* Added file based partitioning to the filejdbc OOTB job
* Refactored FileDeletionJobExecutionListener to be step based

* Move default out of xml for tests

* BatchJobRestartableOptionMixin now a part of mixins.
XD-1849: Consolidate batch resources under /jobs

Change web ui paths
XD-1892 - Update to Spring Platform 1.0.1

- Reinstate forcing of versions but use the Platform's versions
- Update to Spring Hadoop 2.0.1
XD-1777 XD-1794 Restore ModuleDeploymentProperties

- Runtime deployment properties for a given module descriptor needs to be
restored when the module gets deployed upon an arriving container (if this module
was unallocated upon fresh deployment)

- Since it requires the ability to store the calculated runtime properties
(partition properties for example) and re-use when the corresponding module
gets re-deployed, this PR introduces a way to store all the module deployment
requests along with the calculated runtime properties

- Create ModuleDeploymentRequestsPath
  - This path will have all the requested modules upon stream/job deploy
along with any runtime properties and the node `requested` will be stored
under ModuleDeploymentsPath
  - Introduce `moduleSequence` that uniquely represents a given moduleDescriptor
based on the number of modules requested
  - Use ModuleDeploymentRequestsPath to construct and compare all the requested
modules when the deployment unit is deployed/re-deployed

- Change ModuleDeploymentsPath
  - The allocated module deployments path would now be stored under `allocated`
- Create RuntimeModuleDeploymentProperties
  - This represents the runtime properties to be used upon deployment/re-deployment
- Create RuntimeModuleDeploymentPropertiesProvider
  - This provider provides the runtime properties
  - Have DefaultRuntimeModuleDeploymentPropertiesProvider provides the runtime properties
including the sequence number
  - Also, create separate class StreamPartitionPropertiesProvider that handles
partition/short circuit runtime properties for a given stream

- Modify the ContainerListener implementations
  - The arriving/departing container scenarios would handle the deployment/re-deployment
of unallocated/orphaned modules based on the moduleDeploymentRequests path and the runtime
properites stored in there

- Modify ModuleDeploymentWriter
  - The ModuleDeploymentWriter implementations would use runtime properties/provider
while writing the module deployments to the targetted containers

- Refactor the container listeners and deployment listeners
  - Add abstract class `ModuleRedeployer` that handles deployment/re-deployment of modules when
unallocated/orphaned modules are handled
  - Have `Arriving\DepartingContainerModuleRedeployer` extend this
  - Add abstract class `PrimaryDeploymentListener` that handles the fresh deployment of
stream/job modules
  - Have `Stream/JobDeploymentListener` extend this

- Fix tests

2nd commit:

Fix ModuleMetadata Path
 - Add "metadata" in Paths

3rd commit:

Code review changes - phase 1
- Create DeploymentUtils
  - Move DeploymentLoader utility methods into DeploymentUtils
- Fix typo at DepartingContainerModuleRedeployer
- Change `List` -> `Set` for module descriptor collection in
ArrivingContainerModuleRedeployer's deploy stream/job module
- Rename classes and method/var names

4th commit:

Code review changes Part 2

- Use `RuntimeDeploymentProperties` in ContainerRegistrar
- Change Module sequence type from `String` to `int`
  - Update both ModuleDeploymentStatus and ContainerModuleKey

5th commit:

Code review changes - part 3

- Parameterize ModuleDeploymentPropertiesProvider
- Make DeploymentLoader methods as static

6th commit:

Fix ModuleDeploymentWriter method
Fix RemoteFileToHadoopTests

- Add `restartable` property in util properties of test configuration
XD-1873 Make jobexecution list performant

- Remove explicit addition of step executions to each of the job execution in the list
- Change `List` -> `Set` so that `contains` operation would be faster
XD-1929 Add Jolokia dependency

- https://jira.spring.io/browse/XD-1929
Find logging configuration relative to environment

Previously, the scripts all looked for the logging configuration in
$XD_HOME/config (or %XD_HOME%/config).  This caused issues because it
meant that if you moved all of the configuration and overrode
$XD_CONFIG_LOCATION (or %XD_CONFIG_LOCATION%), the logging
configuration changes would not be found in the new location.  This
change updates the scripts to look for logging configuration in
$XD_CONFIG_LOCATION (or %XD_CONFIG_LOCATION%).
The default guava for Acceptance tests is version 15.

Had to set this to version 15 because JClouds will not be able to use any guava above 15 until they release 1.8.