Update documentation

- update steps to run the `s-c-s-module-launcher` on standalone, docker and lattice
 - update recent changes into readme
 - Fix docker compose to use the common binding name so that `time | log` works

Remove explicit cloud profile for lattice run

Remove tap reference

Remove explicit server.port for docker-compose

Update port mapping for docker run

docs/src/main/asciidoc/intro.adoc

@@ -22,7 +22,7 @@ public class TimerSource {
   private String format;
 
   @Bean
-  @InboundChannelAdapter(value = Source.OUTPUT, autoStartup = "false", poller = @Poller(fixedDelay = "${fixedDelay}", maxMessagesPerPoll = "1"))
+  @InboundChannelAdapter(value = Source.OUTPUT, poller = @Poller(fixedDelay = "${fixedDelay}", maxMessagesPerPoll = "1"))
   public MessageSource<String> timerMessageSource() {
     return () -> new GenericMessage<>(new SimpleDateFormat(format).format(new Date()));
   }
@@ -30,18 +30,6 @@ public class TimerSource {
 }
 ----
 
-The `application.yml` has the mapping from channel names to external broker handles (queues, topics, routing keys, etc. depending on the broker), e.g.
-
-.application.yml
-----
----
-spring:
-  cloud:
-    stream:
-      bindings:
-        output: ${spring.application.name:ticker}
-----
-
 `@EnableModule` is parameterized by an interface (in this case `Source`) which declares input and output channels. `Source`, `Sink` and `Processor` are provided off the shelf, but you can define others. Here's the definition of `Source`
 
 [source,java]
@@ -77,7 +65,7 @@ NOTE: In this case there is only one `Source` in the application context so ther
 
 == Multiple Input or Output Channels
 
-A module can have multiple input or output channels all defined either as `@Input` and `@Output` methods in an interface (preferrable) or as bean definitions. Instead of just one channel named "input" or "output" you can add multiple `MessageChannel` methods annotated `@Input` or `@Output` and the names are converted to external channel names on the broker. The external channel names can be specified as properties that consist of the channel names prefixed with `spring.cloud.stream.bindings` (e.g. `spring.cloud.stream.bindings.input` or `spring.cloud.stream.bindings.output`). External channel names can have a channel type as a colon-separated prefix, and the semantics of the external bus channel changes accordingly (a tap is like a topic). For example, you can have two `MessageChannels` called "output" and "foo" in a module with `spring.cloud.stream.bindings.output=bar` and `spring.cloud.stream.bindings.foo=topic:foo`, and the result is 2 external channels called "bar" and "topic:foo".
+A module can have multiple input or output channels all defined either as `@Input` and `@Output` methods in an interface (preferrable) or as bean definitions. Instead of just one channel named "input" or "output" you can add multiple `MessageChannel` methods annotated `@Input` or `@Output` and the names are converted to external channel names on the broker. The external channel names can be specified as properties that consist of the channel names prefixed with `spring.cloud.stream.bindings` (e.g. `spring.cloud.stream.bindings.input` or `spring.cloud.stream.bindings.output`). External channel names can have a channel type as a colon-separated prefix, and the semantics of the external bus channel changes accordingly. For example, you can have two `MessageChannels` called "output" and "foo" in a module with `spring.cloud.stream.bindings.output=bar` and `spring.cloud.stream.bindings.foo=topic:foo`, and the result is 2 external channels called "bar" and "topic:foo".
 
 == Samples
 
@@ -115,25 +103,3 @@ The `[input,output]ChannelName` are used to create physical endpoints in the ext
 For an XD module the channel names are `<group>.<index>` and a source (output only) has `index=0` (the default) and downstream modules have the same group but incremented index, with a sink module (input only) having the highest index. To listen to the output from a running XD module, just use the same "group" name and an index 1 larger than the app before it in the chain.
 
 > Note: since the same naming conventions are used in XD, you can steal messages from or send messages to an existing XD stream by copying the stream name (to `spring.cloud.streams.group`) and knowing the index of the XD module you want to interact with.
-
-== Taps
-
-All output channels can be also tapped so you can also attach a module to a pub-sub endpoint and listen to the tap if you know the module metadata. To tap an existing vanilla module you need to know its `outputChannelName` and the tap name is then `tap:<outputChannelName>`, so you can listen to it on an input channel named `topic.tap:<outputChannelName>`. The tap is only active if you explicitly ask for it: you can do that by POSTing to the HTTP endpoint `/taps/<channelName>` (where the channel name can be the internal or external name, e.g. "output" or the external name mapped to the output channel).
-
-To tap an existing output channel in an XD module you just need to know its group, name and index, e.g.
-
-```
-spring:
-  cloud:
-    stream:
-      group: tocktap
-      name: logger
-      index: 0
-      tap:
-        group: testtock
-        name: ticker
-        index: 0
-```
-
-The `spring.cloud.stream.tap` section tells the module runner which topic you want to subscribe to. It creates a new group (a tap can't be in the same group as the one it is tapping) and starts a new index count, in case anyone wants to listen downstream.
-