Most of the ways we use this field (specifically, all the ways we
use it other than in findMessageListPage) aren't related to it
being the message list in particular.

When we add action sheets other than the message action sheet,
they'll still need a page context.  So prepare the way for those
by giving this a name that can generalize.

And add a bit of docs clarifying the expected practice.

…sheet

We closed issue zulip#24 because it was apparently resolved by an OS
update.  There's still a milder issue; mention that instead.

The usual Flutter idiom, which we use across the rest of the app,
would call for using the parameter called `context` wherever a
BuildContext is required: for getting the store or localizations,
or passing to a method like showErrorDialog, and so on.

That idiom doesn't work here, because that context belongs to the
action sheet itself, which gets dismissed at the start of the method.
Worse, it will sometimes seem to work, nondeterministically: the
context only gets unmounted after the animation to dismiss the action
sheet is complete, which takes something like 200ms.  So the
temptation to use it has been a recurring source of small bugs.

Fix the problem by not passing the action sheet's context to these
methods at all.

…sheet opened

The narrow of a given MessageListPage can change over time,
in particular if viewing a topic that gets moved.

If it does, the mark-unread action should follow along.  Otherwise
we'd have a frustrating race where mark-unread just didn't work
if, for example, someone happened to resolve the topic while you
were in the middle of trying to mark as unread.

Fixes: zulip#1045

This is a nice small bonus from renaming the parameter that was
`messageListContext` to the shorter name `pageContext`.

Some of these don't quite fit in 80 columns.  But the details of
the parameter list are boring (because they're all the same),
so it's OK that some of them go a little over.

These tests are all already relying on the detail that the
setupToMessageActionSheet helper uses `eg.selfAccount` for the
account.  Better to encapsulate that detail, and have them rely
on it giving the test cases a reference to the store directly.

Their callers always give them the shared store prepared by the
setup helper setupToMessageActionSheet.  Have these helpers just
use that directly.

If in the future we end up having a use case for customizing this
behavior, it'll probably be most convenient to have them accept
a connection instead of a store, anyway.