Keep track of topics in ChannelStore

[PIG208]

This is follow-up to #1158.

The initial implementation of the topic-list will fetch topics with API calls. Using the data we have, by listening to changes to PerAccountStore and Unreads, we only know about the topic visibility and unreads changes. But not all of its data is up-to-date.

We need to make sure that the data store is specialized for managing what we know about topics, by channels. Some examples of events that need to be handled:

• message events, for new topics;
• update-message events, for moved or (un)resolved topics.

Since the topic-list page orders the topic by the last message sent, the data structure should keep track of the message IDs in each topic.

Ideally, as a follow-up to this, the data store will also keep track of whether previous requests to fetch topics have failed, but that's of lower priority than handling a similar issue with fetch requests errors from MessageListView.fetchInitial.

[gnprice]

Specifically I'd think of the data structure here as basically recording the results of past calls to https://zulip.com/api/get-stream-topics (the same endpoint that the initial implementation of #1158 will also use) — but then keeping those results up to date with events.

[gnprice]

The main user-facing impact of this, compared to the version in #1500 where those /api/get-stream-topics results are just kept on the state of the _TopicList widget, is:

With the simpler initial version, if the user keeps a topic-list page open while they go and make changes, its list of topics won't get updated. It'll get updated only when they navigate out from the page and then navigate to it afresh, causing a new state to be created and make a new request.

This applies to the names of the topics and their ordering, i.e. the information that comes from /api/get-stream-topics . It doesn't apply to the unread counts, or the muted/followed/etc. states, because those are already part of PerAccountStore and kept up to date with events.