_EncodeLOB expects to get an octet string.

We were passing the character string returned from _DecodeLOB and
persisted by Storable.  This caused checks of validity to fail and
things that should have been encoded in Quoted-Printable to instead end
up being passed directly to PostgreSQL which kicks them back as invalid
UTF-8.

Combined with our change to _DecodeLOB to now strictly decode to UTF-8
and apply Encode::PerlQQ, we should no longer be able to pass invalid
data along to the database.  The Encode::FB_Croak enforces this before
we get to the DB.
Ensure that all calls to _EncodeLOB pass bytes, not characters

There are several places that call _EncodeLOB; most are careful to pass
bytes, not characters:

  1. RT::Attachment->Create takes a MIME::Entity; while the transfer
     encoding will have been decoded, ->bodyhandle->as_string does not
     decode bytes into characters.

  2. ObjectCustomFieldValues from file uploads; these are always left as
     bytes.

  3. ObjectCustomFieldValues from Content which is too long; Content is
     passed as characters.

The one codepath which currently might pass characters, and not bytes,
is the third possibility.  While the Mason parameter munging in
RT::Interface::Web ensures that invalid byte sequences (including for
invalid codepoints, like \x{FDD0}) are replaced using PERLQQ, there are
no such guards for character strings passed to ->AddCustomFieldValue
directly via the API.

Ensure that the LargeContent passed to _EncodeLOB, upgraded from
Content, contains bytes and not characters.
Merge branch '4.2/pass-octets-to-encodelob' into 4.2-trunk