Fix call to c_str() that sometimes dumps core on OpenBSD i386-current

The core dump only seems to occur if mu4e-headers-include-related is
set to t.

Apparently, std::string's c_str() method is confusing to many
people, c.f.
  http://stackoverflow.com/questions/22330250/how-to-return-a-stdstring-c-str

The answer seems to be that the pointer c_str() returns may not be
valid past the current statement; returning it, or even using it
subsequently can have you sending a wild pointer into e.g. g_strdup().

In short, it seems idioms like this are okay:

    return g_strcmp0 (s1.c_str(), s2.c_str()) < 0;

Whereas idioms like this are not:

    const char *msgid (iter->msgid().c_str());

    return msgid ? g_strdup (msgid) : NULL;

At least in my environment by the time we get to g_strdup() the
pointer returned by c_str() is wild and points at garbage.  Since
g_strdup() returns NULL if passed NULL, it seems collapsing it into a
single line is not only possible but necessary.

I've looked at all of the calls to c_str() in mu and it appears to
me this was the one remaining one that was bad.

lib/mu-msg-iter.cc

@@ -366,9 +366,7 @@ mu_msg_iter_get_msgid (MuMsgIter *iter)
 	g_return_val_if_fail (!mu_msg_iter_is_done(iter), NULL);
 
 	try {
-		const char *msgid (iter->msgid().c_str());
-
-		return msgid ? g_strdup (msgid) : NULL;
+		return g_strdup (iter->msgid().c_str());
 
 	} MU_XAPIAN_CATCH_BLOCK_RETURN (NULL);
 }