XD-2408 Fix tap re-deploy issue

   - When a tap is undeployed, the associated tappable module output channel entry was
removed from plugin. We should remove the entry only if the main stream is
undeployed.
      - This way when a tap is re-deployed, the corresponding tap channel
is bound to the module output channel.
XD-2397: Fix CNFE in tcp-client module
XD-2423 Defer WireTap Until Tap Channel Bound

JIRA: https://jira.spring.io/browse/XD-2423

Previously, the `WireTap` was added to the module `output` channel
before the channel was bound to the bus,

There is a race condition where the main stream can start sending
to the tap before it is bound to the bus,  causing 'Dispatcher has no subscribers`
errors. In 1.0.x this would prevent the message from being sent to the
main stream. In 1.1.x, taps run on a different thread so it's just log
noise.

Defer adding the `WireTap` to the tapped module's `output` channel
until it has been bound to the bus as a pub/sub producer.
Fix Test Timing Issue

Caused Travis failure.
XD-2377 Dynamic release links in UI "About" page

* Provide XD version info via `/management/info`
* Add AngularJS service to retrieve version info
* Add version info to About page

XD-2377 Code Review Changes

* Add integration test
* Create a dedicated `VersionResource` class
* Add `VersionController`

Fix Assert in VersionResource
XD-2429 Bind Producer Before Consumer

JIRA: https://jira.spring.io/browse/XD-2429

When tapping a fire hose, it was possible to get `Dispatcher has no subscriber`
errors on the first module's `output` channel.

This was because the `AbstractMessageBusBinderPlugin` bound the consumer (`input`)
first and messages start flowing before the producer (`output` is bound.
If the output channel is a `SubscribableChannel`, `Dispatcher has no subscribers`
resulted.

Change the bind order so that the output channel is bound first, then the
inbound channel. Similar to the way we bind modules right-to-left when using
a `LocalMessageBus`, we need to bind the module itself right-to-left.

This is only a problem when a stream starts with a tap because, with a "normal" stream,
the last module to be bound is the source, and we don't start it until the source itself
is bound; hence no messages flow to the downstream processors so it doesn't matter what
order their channels are bound.

With a tap, messages can start flowing from the tap as soon as the input channel is bound to the bus.
XD-2377-2 Add `$scope.$apply` to `about` controller
XD-2409 Changing correlation-strategy-expression

- this will avoid some issues ecountered with SpEL (SPR-12502)

- using "payload.class.name" seems to work in all cases
XD-2342 Fix JDBCHDFS Job Password issue

* Add test-cases
* Make `xdFormatStream` more robust

XD-2342 Update server-side regex

* Add unit tests
XD-2409 Changing correlation-strategy-expression

- for spring-xd 1.0.x branch

- partial reversal of earlier change to avoid errors when payload is a String
Add description to spring-xd-yarn pom generation
XD-2316 Fix batch config REST endpoint

 -  If the batch job is not deployed and has no entry in batch job repository,
the detailed job info will not be added for that job. We will only show the job
definition/deployment status from XD ZK repositories.
 - Also, make the `/batch/configurations` endpoint to produce only `application/json`
XD-2485 Update spring-data-hadoop version to 2.0.4 for XD 1.0.x