cleanup versions in build.gradle
XD-1585: Completions after a named channel
XD-1728 UI:Add Support for Bold/Strong Fonts

Moved `strong` CSS declaration to `typography.less`
Clean Up Rabbit Queue foo.props.0-0
XD-1807 Paging support for repositories

* Add utility class `PagingUtility` that returns the page implementation of
the given `Comparable` list
* Make `ModuleMetadata`, `ContainerAttributes` and `ModuleDefinition` of type
`Comparable`
* Update all the repositories `findAll(Pageable)` to use type specific
PageUtility's paged data
* Address review comments
** Add missing `Javadoc`
** Add the null check on `Pageable` at the PagingUtility
** Add assertion message on PagingUtility
** Use List.sublist while slicing
** Add PagingUtilityTests
XD-1622: Added the display of the batch step type to the UI
* Added code to pull step type out of the StepExecution's
 ExecutionContext.
* Added code to pass type to UI.
* Updated Spring Batch version to the current snapshot to use updates
 made in batch to support this feature.
XD-1311 XD-1767 JobExecution deployed/deleted status

- Add `deployed` and `deleted` status to JobExecutionInfoResource
- At BatchJobExecutionsController:
  - If the job name exists in the `JobDefinitionRepository` but not at the
`JobLocator` then we would set the jobExecution deployed status to `false`
  - If the job name doesn't exist in the `JobDefinitionRepository` at all,
then we would set the deployed/deleted status to `false`
- At the web UI:
  - Add the label to denote the deployed/deleted status at the
JobExecutions list page
- Fix tests

Add job existence status

Call setter methods from controllers

- Set `Deployed` and `Deleted` status based on the conditions rather than depending on the default value
at the `JobExecutionInfoResource`

Add Javadoc

Modify logic to call the setter methods

Fix BatchJobExecutionsControllerIntegrationTests

- Make jobLocator to return empty list so that all the jobs in test are
considered to be `undeployed`.
XD-1477 Merge Container & ContainerAttributes

- Rename `ContainerAttributesRepository` with `ContainerRepository`
  - Also, `ZooKeeperContainerAttributesRepository` to `ZooKeeperContainerRepository`
- Remove existing `ContainerRepository` that returns the containers iterator
  - Use the newly added ContainerRepository as the dependency instead.
- Compose `ContainerRepository` into `DeploymentSupervisor`
  - Update all the dependent listeners to use this container repository
- Move ContainerAttributes into Container
- Create `ContainerResource` REST domain resource that holds ContainerAttributes
- Update Runtime container command operations
- Fix tests
XD-1812 Dynamic Producer Properties

Pass properties to the bus for dynamically bound channels,
such as those used by the router sink.

- Add the module's producer properties to the module's
   `MessageBusAwareChannelResolver`, which is added as the
   channel resolver for any `AbstractMappingMessageRouter`
   found in the module's context. `StreamPlugin` extracts
   the producer properties and makes them available to the
   module's `MessageBusAwareRouterBeanPostProcessor`.
- When it is determined that the producer needs to be dynamically
   created, pass the properties into the bus along with the
   bind request.
- XD-1707 incorrectly registered a second producer for named
   channels if a named channel consumer was deployed before
   a named channel producer. Remove that logic and add a
   condition to the `AbstractSingleNodeStreamDeploymentIntegrationTests`
   which expected the named channel bean to exist after the
   consumer is bound. With buses other than the `LocalMessageBus`,
   the producer channel bean is not created until the producer is
   bound.
- Minor refactoring in the `RabbitMessageBus`, producer properties
   were incorrectly applied twice to some adapters.
- Enhance `SingleNodeIntegrationTestSupport` to support deployment
   properties and enhance dynamic producer tests to verify the
   properties are set.

XD-1812 Polishing - Handle Bad Properties

Previously, if the dynamic channel had bad properties (e.g.
partitioning), a 'Dispatcher has no subscribers' error would
be logged, when retries are exhausted.

When a dynamic producer is bound, we create and register
a direct channel which is then bound to the bus, this channel
is returned by the resolver.

If the bind failed, the channel remained in the context so when
retry was attempted, we got 'Dispatcher has no subscribers'.

Add code to remove the channel from the context if the bind
fails.

Restructure a little so overridden methods in the local bus
can use common code.

Add a unit test for the bad properties.

XD-1812 Polishing; PR Comments

The initial commit removed `registerNamedChannelForConsumerIfNecessary`
which was incorrectly added to create a producer when a named channel
consumer was registered before a producer.

The commit that introduced that method also added `destroyCreatedChannel`
to remove the channel created for that producer.

This commit removes that method, since it is no longer needed (it will
never find a channel to remove). The set `createdChannels` is no longer
needed either.

Test the channel actually existed before removing it from the context.

Fix typo in JavaDoc.
XD-1591: Flatten out ephemeral nodes

Containers that write out ephemeral nodes indicating deployment
of a module previously used the following node structure
for streams:

/xd/deployments/streams/<name>/<type>/<label>/<container>

This has been modified to look like this:

/xd/deployments/streams/<name>/<type>.<label>.<container>

This change will make it easier to create ZooKeeper watches
on the stream to detect the addition/removal of modules
and thus calculate the state of the stream.

Addressed review comments
XD-1517 seperate /deployments and /definitions and related changes
XD-1517 Fix AdminUI

- Update changed REST URLs for streams/jobs definitions and deployments paths
Fix integration test scripts