INT-3998: Channel Late-Binding for WireTap

JIRA: https://jira.spring.io/browse/INT-3998

Do not modify interceptors from the `AbstractMessageChannel`.

They must be declared as beans, too.

Fix [UnusedImport] in the `EnableIntegrationTests`

Doc Polishing

src/reference/asciidoc/channel.adoc

@@ -788,6 +788,30 @@ That way, the framework will ask the interceptor if it's OK to intercept each ch
 You can also add runtime protection in the interceptor methods that ensures that the channel is not one that is referenced by the interceptor.
 The `WireTap` uses both of these techniques.
 
+Starting with _version 4.3_, the `WireTap` has additional constructors that take a `channelName` instead of a
+`MessageChannel` instance.
+This can be convenient for Java Configuration and when channel auto-creation logic is being used.
+The target `MessageChannel` bean is resolved from the provided `channelName` later, on the first interaction with the
+interceptor.
+
+IMPORTANT: Channel resolution requires a `BeanFactory` so the wire tap instance must be a Spring-managed bean.
+
+This _late-binding_ approach also allows simplification of typical wire-tapping patterns with Java DSL configuration:
+[source,java]
+----
+@Bean
+public PollableChannel myChannel() {
+    return MessageChannels.queue()
+            .wireTap("loggingFlow.input")
+            .get();
+}
+
+@Bean
+public IntegrationFlow loggingFlow() {
+    return f -> f.log();
+}
+----
+
 [[conditional-wiretap]]
 ===== Conditional Wire Taps
 

src/reference/asciidoc/whats-new.adoc

@@ -206,3 +206,9 @@ See <<annotations>> for more information.
 
 The XMPP Extensions (XEP) are now supported by the XMPP channel adapters.
 See <<xmpp-extensions>> for more information.
+
+==== WireTap Late Binding
+
+The `WireTap` `ChannelInterceptor` now can accept a `channelName` which is resolved to the target `MessageChannel`
+later, during the first active interceptor operation.
+See <<channel-wiretap>> for more information.