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
The intent here is to extract the portions of the `JobsDeploymentPath` that indicates the module that the path is referring to. This is used later to compare with the actual deployed jobs to see which ones are missing. Right now we only ever have one job module, but it was done this way to be consistent with how streams (which do have multiple modules) are examined.

I think we should carefully consider how this is done. The JavaDoc for this method indicates that it returns the "module this path represents." However, what it *actually* returns is a string of the format `type.label.sequence` which IMO is very much an internal implementation detail of the module representation. If this format were to change, we would have to change this method and everything else that consumes it.

Here are a few suggestions I can think of:
* Encapsulate this data into a separate class...perhaps `RuntimeModuleDescriptor` or something along those lines? If we introduce such a class, would it come in useful in other places?
* Leave the implementation as is, but clearly document the format of the string being returned
* Return an array or collection of strings, with the doc indicating what each slot in the array is representing