net_imap: Add THREAD=REFERENCES algorithm.

This adds support for the canonical threading
algorithm formulated by Jamie Zawinski while
at Netscape, formalized in RFC 5256. This is the
preferred threading algorithm.

Step 5 of the algorithm is skipped in this implementation,
since MUAs today do not (and should not) thread messages
based on the subject alone, as ORDEREDSUBJECT does.

Step 6 of the algorithm is embedded in the parent/child
linking function, and thus does not need to be done
separately.

One liberty taken in this implementation, not specifically
discussed in either the RFC or JWZ's writeup of the algorithm,
is how to handle dummy messages beneath the root that have
multiple children. In particular, step 3 of the algorithm
in the RFC says for dummy messages with children, children
should be promoted to the current level unless they would become
children of the root, unless there is only one child. However,
dummy messages can obviously not appear in the final thread results.
The sensible thing MUAs seem to do is promote the first (oldest)
child to the parent in these cases, and so that is the approach
adopted in this implementation. The official algorithm does not
explicitly say to do this, but this seems to be the right thing to do.

bbs/menu.c

@@ -580,7 +580,7 @@ static int bbs_menu_run(struct bbs_node *node, const char *menuname, int stack,
 		/* Hey, guess what, we're still holding a RDLOCK on the menu. See what this option is for. */
 		/* We don't need to call MENUITEM_NOT_APPLICABLE here to check if it applies, it wouldn't be in the options buffer if it wasn't */
 		menuitem = find_menuitem(menu, opt);
-		bbs_assert(menuitem != NULL); /* It was in the menu and the menu hasn't changed, it better exist. */
+		bbs_assert_exists(menuitem); /* It was in the menu and the menu hasn't changed, it better exist. */
 		node->menuitem = menuitem->name;
 
 		opt = 0; /* Got a valid option, display the menu again next round */