Handle Zulip-internal links by navigation

[gnprice]

This is a followup to #71 that will only make sense after we have #72 as well.

Once we recognize the user tapping on a link in a message (#71), and we have UI for a variety of narrows (#72), we'll want to start recognizing when a link refers to another Zulip narrow. Then we can follow the link by navigating to that narrow within the app, rather than opening it in a browser.

This is a key part of the UX when reading a conversation that refers to other conversations and messages, because opening them in a browser will typically mean having to log into Zulip anew.

[gnprice]

The prerequisites #71 and #72 are complete. I believe what's needed for this issue is now:

• Move narrowLink and its private helpers out of lib/model/compose.dart and into their own file, like lib/model/internal_link.dart.
• In that file, add a sort of inverse to narrowLink: a function that takes a link and converts it to a Narrow value, returning null if the link isn't to a narrow on the current realm.
  • This will definitely want unit tests.
• Then when the user taps a link to open it (msglist: Make links touchable, opening in browser #71), before we go and try to launch the URL in a browser, try to parse it to a Narrow. If that succeeds, navigate to that narrow, in the same way as we do when the user touches a recipient header.

Two aspects I'd like to leave out of scope for this issue are:

• Handling /near/… operators in links. That's Open a message list in the middle of history, when requested #82. Instead, for this issue, just ignore the /near/… operator and go to the narrow.
• Handling topics that have moved. We can file a followup issue for handling that wrinkle. (It's alluded to in api: Add getMessageCompat helper, for servers with and without FL 120 #177.)