This series adds a library API for iterating over all messages in a thread in sorted order. This is easy for the library to provide and difficult to obtain from the current API. Plus, if you don't count the code added to the bindings, this series is actually a net decrease of 4 lines of code because of simplifications it enables. Do we want the API to do more? Currently it's very minimal, but I can imagine two ways it could be generalized. It could take an argument to indicate which message list to return, which could be all messages, matched messages, top-level messages, or maybe even unmatched messages (possibly all in terms of message flags). It could also take an argument indicating the desired sort order. Currently, the caller can use existing message flag APIs to distinguish matched and unmatched messages and there's a separate function for the top-level messages. However, if the API could do all of these things, it would subsume various other API functions, such as notmuch_thread_get_*_date. Also, is this the right name for the new API? In particular, if we do later want to add a function that returns, say, the list of matched messages, we'll have a convention collision with notmuch_thread_get_matched_messages, which returns only a count.