Fix a syntax error
Switch to just loading fixtures in tests as binary strings

The data loaded with load_file_fixture is generally used
in the tests as if it were binary data received from the
MTA, so just load it as binary data - in Ruby 1.9 this means
that it will end up with the encoding ASCII-8BIT.

The same is the case when reading data from a fixture file
in receive_incoming_mail.
Add a new example for unconvertible-to-UTF-8 text part data

The example file that was used for checking for text
attachment data which could not be converted to UTF-8 is
one that we *can* actually deal with by guessing the
character set, since it's valid GB18030.  So, this commit
changes that test to check for the first few Chinese
characters in that email, and introduces a replacement
test with text from /dev/random, which should not be
interpretable in any sensible way.
Add functions for converting from arbitrary text data to UTF-8

Throughout the codebase it is simplest and most consistent
if we could assume that all text/* attachments are represented
by UTF-8 strings, and this was largely true with the TMail
backend which ensured that all returned text parts were in
UTF-8.  We have to change the replacement Mail-backed to
similarly attempt to convert text parts to UTF-8.  This commit
introduces two functions which are useful for this.

The normalize_string_to_utf8 function will try various
encodings, either suggested or guessed (with charlock_holmes)
to convert the passed string to UTF-8, and if it can't find a
suitable encoding will throw an exception.

Unfortunately, the current behaviour of the site is that
uninterpretable text/* attachments are still passed around and
mangled to UTF-8 just before display.  To mimic this it's also
useful to have the convert_string_to_utf8_or_binary function,
which tries to convert the string to UTF-8 with
normalize_string_to_utf8, but if that's not possible just
returns the original string.  (In Ruby 1.9, encoding will be
set to UTF-8 or ASCII-8BIT appropriately.)
Make efforts to ensure that we're usually dealing with UTF-8 strings

One of these changes is to make sure that the Mail backend,
like the TMail backend it replaces, will return text parts
encoded in UTF-8 if possible.

The other change is to ensure that when text attachments are
reloaded from disk, we attempt to convert them to UTF-8.
Add a helper function for dumping text to disk

This function is useful for investigating problems with
handling of emails, attachments and the related character
encoding issues.  It can safely be removed later, but is
currently useful to have for debugging purposes.
Add another mail parsing test

At one point in development this email was misparsed, so I've
added this as test to check for regressions.