model more-unified handling of Reply and Message objects

[cfm]

Between #1493 and #1486, we discovered the following asymmetries in how messages (i.e., of different kinds and directions) are handled in the Client:

1. DraftReply objects are separate from, rather than states of, Reply objects;
2. Reply objects are separate from, rather than directions of, Message objects (granted, they are in the Server's data model too);
3. replies sent to the Journalist API can be pending, successful, or failed; and
4. messages (including replies) reported by the Journalist API can be not yet downloaded, downloaded, or failed.

This is a stub ticket to track an effort to consider and model to what extent we can resolve these asymmetries into one (Message) or two (Message and Reply) well-defined state machine/s (a) entirely Client-side or (b) with changes also to the Journalist API and its backing data model.

[cfm]

My working model is available in https://gist.github.com/cfm/2ca373e7ac5e5397550d7db98289dc3d, which I'll write up in a formal proposal this week.

[cfm]

We dropped this in #1632 (comment).