Thread sorting by most recent message - rewrite for speed

Since commit c7b28419abd9 ("* bugfix for issue 164") I have experienced a slowdown when displaying messages in threaded format.

On a 16k maildir, using mu from master @ c7b2841, threading and sorting by date takes:
```
$ perf stat --event=task-clock --repeat=10 -- \
  mu find maildir:/INBOX -n 1 -t > /dev/null

 Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):

       5242.073458      task-clock (msec)         #    1.000 CPUs utilized            ( +-  0.50% )

       5.244428658 seconds time elapsed                                          ( +-  0.50% )
```
While one commit before that (master @ bd9d99a) it takes only:
```
$ perf stat --event=task-clock --repeat=10 -- \
  mu find maildir:/INBOX -n 1 -t > /dev/null

 Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):

       1231.761588      task-clock (msec)         #    0.996 CPUs utilized            ( +-  1.02% )

       1.236209133 seconds time elapsed                                          ( +-  1.08% )
```
In addition to that, I noticed that current thread sorting implementation stops looking for the most recent message at an empty container that serves as a parent to orphaned siblings messages.

This is a rewrite of commit c7b2841. The goal was to get the thread sorting performance back to what it was before and to keep the behavior as is. (Except for the case where a thread contains orphaned siblings.)

After the rewrite, the time it takes to sort threads has dropped down back to a level that I'm happy with:
```
$ perf stat --event=task-clock --repeat=10 -- \
  mu find maildir:/INBOX -n 1 -t > /dev/null

 Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):

       1459.883316      task-clock (msec)         #    0.998 CPUs utilized            ( +-  0.72% )

       1.462540088 seconds time elapsed                                          ( +-  0.77% )
```
On the way, I've extended mu's test suite for threads to ensure that that I haven't broken the behavior that commit c7b2841 introduced. So far everything have been working as expected for me.

Note on the implementation: to get the performance back to what it was I've exploited the time-memory tradeoff. Instead of iterating over the containers, each container keeps a pointer to the most recent message in the (sub)thread rooted at this container. The pointer is propagated as we visit the containers during sorting, starting at the leaf nodes and going up the tree.