tests: threads: Use struct tinfo in all tests
tests: threads: Extract helpers for initializing and comparing thread info
tests: threads: Extract helper for checking thread info for each message
tests: threads: Test if 1st child message promotes its thread
tests: threads: Test if 2nd child message promotes its subthread
tests: threads: Test if orphan message promotes its thread
tests: threads: Test if child message doesn't promote its thread
tests: threads: Test if grandchild message promotes its thread
tests: threads: Test if grandchild message promotes only its subthread
Revert "* bugfix for issue 164"

This reverts commit c7b28419abd9d53ff36412e4fedaf308ce13c552.

The reverted change fails to sort threads correctly when there is an
empty container, serving as a parent to orphan messages, in the thread
tree as demonstrated by the test in commit f49296759ef8 ("tests:
threads: Test if orphan message promotes its thread").

Also, the reverted commit introduces a performance hit. The time it
takes to sort threads has increased roughly by a factor of 4.

Current state:

$ 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):

       4967.692519      task-clock (msec)         #    1.000 CPUs utilized            ( +-  0.14% )

       4.969247128 seconds time elapsed                                          ( +-  0.14% )

With the reverted patch applied:

$ 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% )

The benchmark was ran on a maildir with ~16k messages:

$ mu find maildir:/INBOX | wc -l
16503
mu: Extract function for comparing two containers
mu: Consider an empty container to be less than anything else

Reasoning being that, arguably, it is the least surprising thing to do.
mu: Prune empty container when an only child gets promoted to the root set
mu: Update container's pointer to last sibling when converting from a list
mu: Sort containers by comparing their subtree leaders

Traverse the container tree depth first and for each container find
the node in the subtree rooted at this container which comes first in
the descending sort order. Remember it as the subtree leader. Then,
while sorting siblings, compare their subtree leaders instead of the
sibling containers themselves.

IOW, make threads containing the newest message float to the top when
sorting by date in the descending order.

There is no significant performance degradation when sorting a
mailbox with ~16k messages:

$ mu find maildir:/INBOX | wc -l
16503

Current state:

$ 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% )

With patch applied:

$ 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% )

This implements https://github.com/djcb/mu/issues/164.
Merge pull request #455 from jsitnicki/thread-sort

* Thread sorting by most recent message - rewrite for speed