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
If we get rid of `RuntimeModuleDeploymentPropertiesProvider` then we would have to cast the properties returned by `ModuleDeploymentPropertiesProvider` to `RuntimeModuleDeploymentProperties` when we need a sequence number (for instance, see `ModuleDeploymentWriter.writeModuleDeployment`). If we instead decide to get rid of `ModuleDeploymentPropertiesProvider` and keep `RuntimeModuleDeploymentPropertiesProvider`, then we would always have to determine the sequence number for a particular module. This is cheap on initial deployment and expensive on redeployment since obtaining this information requires a ZK read for each module - and in the case of redeployment is only required for the module actually being deployed. On the other hand we need to obtain the count for each module in the stream to recalculate the stream state after redeployment.

Hope that all makes sense - we can talk more in the morning.