Review UX of compose box in interleaved narrows

[gnprice]

The Zulip compose box in all clients has always been a tricky balancing act for the UX, for any situation where the message list the user is looking at doesn't correspond to a single conversation (i.e. any "interleaved" narrow). We want it to be easy to reply in the conversation you want to reply in; but hard to accidentally reply in an unintended conversation out of those you're looking at; and also to be easy to start a new topic.

The current prototype takes an approach that's optimized more for implementation simplicity than for this UX balance. That's fine for the alpha, but we should revisit it for the beta, or certainly before launch. We should have either the behavior that's in zulip-mobile, or something we think will be better.

@chrisbobbe writes at #147 (comment) :

For when and how to present a compose box, I think we could do some more design work in a later phase, to not re-introduce issues like these:

• "Every time I type a response it ends up responding to the wrong topic" zulip-mobile#3945
• suddenly need to select topic before replying to post (since 27.1xx)  zulip-mobile#5024

[…]

For example, one way I think it could work is:

• De-emphasize interleaved stream views in the navigation
• For topic and DM-conversation views, give a compose box that doesn't offer changing the destination conversation (topic or recipients, respectively).
• For other views (e.g. all-messages; stream views; arbitrary narrows), don't show a compose box until the user asks for one, with "reply" or "quote and reply" on a specific message. The compose box will send to that message's conversation, without offering a change of destination, since that could lead to confusion and accidents.
• Offer a "new topic" UI: Explicit "New topic" UI zulip-mobile#4379

[gnprice]

Filed #310 for the portion of this we should be sure to do for the beta.