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
I was thinking along these lines:
* For an initial deployment we need the `Runtime` properties in order to deal with sequence numbers for all modules. These properties are all created at deployment time.
* For a re-deployment, we only need `Runtime` properties for the module being redeployed. However, we need to know the expected count for *all* modules in order to calculate the stream state. Using `Runtime` properties is overkill for this since we can obtain the count from the deployment properties issued at deployment time.

This is `DeploymentUnitStateCalculator`:

```
	DeploymentUnitStatus calculate(DeploymentUnit deploymentUnit,
			ModuleDeploymentPropertiesProvider provider,
			Collection<ModuleDeploymentStatus> deploymentStatuses);
```

Given these requirements, do you think we can get away with just `ModuleDeploymentPropertiesProvider` or do we need to make a distinction for runtime properties?