Re-indent _EncodeLOB and _DecodeLOB
Respect the database Content-Type header in decoding textual parts

The definition of "texual" data has changed over time.  Specifically,
7365c08 caused text/html messages to begin being stored as utf-8 in the
database; prior to that, the claimed "charset" and bytes in the body
were left unmolested during insertion.

text/html attachments inserted into the database prior to 7365c08,
however, are now expected to be utf-8 when being extracted from the
database.  This causes PERLQQ'd garbage to be displayed for the non-UTF8
content stored in the database.  This type of error is likely to also
re-occur in the future whenever the definition of "textual" data
(i.e. data we transcode on insertion) changes.

Respect the Content-Type header when decoding data from the database, or
guess its value from the body; this mirrors the logic in
RT::I18N::SetMIMEEntityToEncoding, which is what is done for
currently-detected-as-textual parts on insert.  In cases like text/html
prior to 7365c08, the Content-Type header was not altered during
database insertion -- and at worst, the claimed character set is
incorrect and decoding will result in PERLQQ'd garbage.  This is no
worse than said message were detected, received, converted, and stored
in the database as text.
Stop needlessly frobbing utf8 internals

bf87c784 swapped in this explicit _utf8_off for what had been a
_utf8_on.  As the values are fetched with decode_utf8 => 0, $content
contains bytes, not characters.  Explicitly turning of fthe utf8 bit is
unnecessary, as they are already bytes.
Decoding content, and returning characters, is incorrect

The whole purpose of this function is to return bytes, not characters.
Decoding the bytes to characters as utf8 defeats the purpose, and only
works because RT's internal representation of characters happens to be
utf8, which gets used by MIME::Entity to later encode the characters.

Switch to simply returning the bytes, as-is.
Stop assuming the data in the database is utf8

As noted in 18c810d0, not all content we currently call "texual" was
always treated as such.  When re-encoding, do not assume that the
encoding in the database is UTF-8 -- rather, read the Content-Type
header, and examine the charset stated there.  Convert from that to the
original encoding.
Merge branch '4.2/old-html-encoding' into 4.2-trunk