Add notes about merge, multiMap, and multiple input channels

[bentsherman]

From some other discussions (#2113 #2682), it looks like some users like to use the following pattern:

1. start with a channel of tuples or maps
2. use multiMap to split tuple/map into individual channels
3. invoke process with the channels from (2) as inputs
4. re-combine any output channels from (3) with merge

I think this pattern is used in order to avoid having long tuples for process input/output, but actually I think tuples are the best practice here, and this multiMap+merge pattern should be discouraged, because there is a risk of items not being re-combined correctly. I think it happens to work for now but order preservation is not guaranteed in principle.

I think the broader issue is that users would like to have better support for optional inputs/outputs and named inputs (i.e. map input), and this pattern is a sort of workaround for that. But for now I think we should reinforce the best practice in the docs, so in this PR I added some clarifications around use of merge, multiMap, and multiple input channels.

[bentsherman]

Added a deprecation warning to merge because it is actually deprecated in DSL2 according to the code. Apparently it's only allowed in DSL1.

[pditommaso]

Nice