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.
XD-1545 Acc testing for multiple containers

1. Test no longer relies on artifact to know what containers are available.  This is queried from admin.
2. Test finds the container where source, processor, job & sink modules are deployed.
3. Mapped ec2 internal dns to external dns.
4. Tests handle x containers for source & job file based tests.
5. Sample properties container settings have been removed.
6. jclouds-ec2 dependency added to build.gradle.  It is compile time since it is utility based.