mime_fromhdr(): fix my rewrite again..

mime_fromhdr(): fix my rewrite again..

My hasty rewrite [0f9ad93] (mime_fromhdr(): partial rewrite using
n_iconv_str(), 2013-03-12), just about ninety (90) minutes before
the release of S-nail v14.1 already caused the bugfix [b608c6b]
(mime_fromhdr(): never return NULL output.., 2013-03-14), which
was the sole reason for the release of S-nail v14.2.

Well, about a year later, after tens of thousands of mails,
including multibyte ones, i wrote myself a message that has shown
that the rewrite was still buggy -- the header

  Subject: ehm, .getElementById("blink") needs <span
   =?US-ASCII?Q?id=3D"blink">,?= not =?US-ASCII?Q?class=3D"id"?=

cannot be viewed correctly, the ", not" will be lost.
The reason is now understood and this changeset should fix
mime_fromhdr() so that it'll do what it is assumed to do in the
current codebase, unless i'm terribly mistaken.

Because i bickered some time in private, i WANT to add that the
real problem is that the codebase is weird INSOFAR as that i still
don't really understand the WAY it works, because THAT IS SICK.
I.e., in my brain i assume this function effectively is
rfc_2047_decode(), meant to decode encoded words as specified in
RFC 2047, but that's simply not true, and FOR QUITE SOME TIME,
because of the embedded newlines that may be in the data and need
to passed through for at least the case that we send data to the
display.  I slowly get around that schizophrenic codebase while
also converting it to a straight one, but that will take years.
Until then we need to strip whitespace in between multiple
adjacent encoded words, while passing through newlines and
whitespace that follows newlines, regardless of whatever.
I hope this will do it until we are sane.