[WIP] Show a summarised snippet of the latest reply from each thread

[joshuathayer]

Resolves #135.

This reopens @timruffles 's PR (#161) against a branch in our own repo.

@eloquence commented in #161 regarding some UX problems with this feature, which I'll copy below. This PR will be left as WIP until these issues are addressed:

There are a few issues with this from a UX perspective at present:

1. When the text exceeds the width of the source list, it causes the source list to require horizontal scrolling. To reproduce, create a source with a message like "Everything in one line. Everything in one line. Everything in one line. Everything in one line."

2. This PR implements a feature that's not in the spec -- a "↳" is inserted before messages that originate from the source (as opposed to replies). That's an interesting idea, but if we add a feature like that, we'll want to do some more thinking about doing it in a more intuitive way. Note that Signal, for example, does not indicate the provenance of snippets and generally relies on the user's memory for that.

3. When a file is submitted after a message, only the placeholder "↳" is shown. Instead, per the spec, the most recently received message should be shown.

4. When all we have is a single file (no later messages or replies), contrary to the specification, no text "—submitted a file, no message—" is shown as a snippet.

5. When the text contains many newlines, it can take up to the entire height of the source list, or more.

Suggested minimal amendments from a UX perspective before merging:

1. Wrap text to two lines at a width that corresponds to the width of the source widget.

2. Remove ↳ feature for now.

3. Swallow line breaks and replace them with spaces:

a.

b

c

becomes:

a. b c

4. Show most recent message or reply if most recent submission is a file.

5. Implement "single file, no messages or reply" behavior

Finally, note that after downloading a file, its preview snippet is replaced with . I am not listing this above because files should be special-cased, anyway, per the above. NB: I stepped through this in detail with @ninavizz and she agrees with these recommendations.

[eloquence]

A bit more on the wrapping behavior.

We should account for the fact that the client window size may be changed depending on user preferences and screen resolution; the source list currently dynamically scales with it. In future we may even want to make it sizable.

Given this, it seems advisable to have a snippet of the longest plausible size (test on HiDPI display with maximum window size) in-memory and to handle the abbreviation dynamically based on the widget's size. Otherwise we will have situations like this:

------------------
preview text 
wraps to three
lines ...

---------------------------------------------------
preview text stops abruptly ...

[heartsucker]

Suggesting we close this it is superseded by #339 and requires extensive rebasing to be mergeable.

[eloquence]

As @heartsucker says, this will be superseded by #339. Closing.