anchors 6/n: Start splitting slivers!

[gnprice]

This is the next round after #1436 (and is stacked atop it), toward #82.

This is a draft because there's one remaining user-visible bug: the scroll-to-end button goes to a point above the end. I'm posting the draft because it's useful for manually testing the changes in #1436, by making them apply in the real Zulip message list.

In this PR:

• (I'll make some changes to the scroll-to-end button. This PR is a draft because those aren't written yet.)

• We start actually splitting the message list into back-to-back slivers, with the latest message in the bottom message list. Thanks to all the prep work up to this point, this change has only subtle effects in the UX.

• The last commit takes advantage of the back-to-back slivers to make one nice, though small, UX improvement: when opening a message list where the latest message doesn't fit on the screen or nearly doesn't, we make sure to show the top of that latest message instead of the bottom.

  In the future when the bottom sliver represents the unread messages, or the messages starting at another target anchor (anchor in the Zulip sense, not the ScrollView sense), this change will become much more important: we'll need to show the top of that potentially very tall bottom sliver, not its bottom.

Selected commit messages

26d2d3a WIP msglist: Split into back-to-back slivers; TODO test?; TODO scroll-to-end show, act; TODO weaken test on crossing slivers

Thanks to all the preparatory changes we've made in this commit
series and those that came before it, this change should have only
subtle effects on user-visible behavior.

In particular:

• The sticky headers should behave exactly as they did before,
  even when the sliver boundary lies under the sticky header,
  thanks to several previous commit series.

• On first loading a given message list, it should start out
  scrolled to the end, just as before.

• When already scrolled to the end, the message list should stay
  there when a new message arrives, or a message is edited, etc.,
  even if the (new) latest message is taller than it was.

Subtle differences include:

• When scrolled up from the bottom and a new message comes in,
  the behavior is slightly different from before. The current
  exact behavior is something we probably want to change anyway,
  and I think the new behavior isn't particularly better or worse.

• The behavior upon overscroll might be slightly different;
  I'm not sure.

This therefore serves as a testing ground for all the ways that the
message list's scrolling behavior can become more complicated when
two (nontrivial) slivers are involved. If we find a situation
where the behavior does change noticeably, that will be something
to investigate and fix.

6e03b9e scroll: Show start of latest message if long, instead of end

This makes our first payoff in actual UX from having the message list
split into two back-to-back slivers!

With this change, if you open a message list and the latest message
is very tall, the list starts out scrolled so that you can see the
top of that latest message -- plus a bit of context above it (25% of
the viewport's height). Previously the list would always start out
scrolled to the end, so you'd have to scroll up in order to read
even the one latest message from the beginning.

In addition to a small UX improvement now, this makes a preview of
behavior we'll want to have when the bottom sliver starts at the
first unread message, and may have many messages after that.
This new behavior is nice already with one message, if the message
happens to be very tall; but it'll become critical when the bottom
sliver is routinely many screenfuls tall.