Define some new SMB hfield types:

- REPLYTOLIST (a mime-decoded version of RFC822REPLYTO)
- RECIPIENTLIST (a mime-decoded version of RC822TO)
- RFC822CC (a mime-encoded version of SMB_CARBONCOPY)
- RFC822ORG (a mime-encoded version of SMB_ORGANIZATION)
- RFC822SUBJECT (a mime-encoded version of SUBJECT)

The RFC822* hfields are only created when necessary: there was a MIME-encoded
hfield value received (e.g. by the mailsrvr) for the corresponding hfield.

The to_list and replyto_list convenience pointers now point to the MIME-decoded
(plain text) version of these header fields, since that's what everyone
normally wants to see and use.

The MIME-encoded flavors (RFC822*) are stored for relaying via SMTP or POP3
and retaining all data (no normalization or decoding).

A new auxattr bit has been defined: MSG_HFIELDS_UTF8 (happens to be the same
as P_UTF8 - snicker). This bit will be set in msg.hdr.auxattr when one or more
hfield values are in UTF-8 format. When this flag is not set, all hfield values
are assumed to be CP437 for backwards compatibility.
Since we are using a single flag, all header fields have to use the same
encoding (either CP437 or UTF-8). When the hfield values are all plain ASCII,
there's no difference between CP437 and UTF-8 and the MSG_HFIELDS_UTF8 flag
is not expected to be set, though setting it shouldn't hurt. The RFC822* hfield
values should also include US-ASCII text (using MIME-encoding for any 8-bit
charsets).

smb_get_hfield() function prototype change: the 3rd argument changed from
an hfield_t* to an hfield_t**, so that the caller can actually change the
hfield type (in memory) if they wish. Nobody seemed to be passing any non-NULL
3rd argument value, so this changed appeared safe to make.