decode_rfc2231(): Be more robust against buggy RFC 2231 encodings.
Specifically, instead of raising a ValueError when there is a single
tick in the parameter, simply return that the entire string unquoted, with
None for both the charset and the language.  Also, if there are more than 2
ticks in the parameter, interpret the first three parts as the standard RFC
2231 parts, then the rest of the parts as the encoded string.

More RFC 2231 improvements for the email 4.0 package.  As Mark Sapiro
rightly points out there are really two types of continued headers
defined in this RFC (i.e. "encoded" parameters with the form
"name*0*=" and unencoded parameters with the form "name*0="), but we
were were handling them both the same way and that isn't correct.

This patch should be much more RFC compliant in that only encoded
params are %-decoded and the charset/language information is only
extract if there are any encoded params in the segments.  If there are
no encoded params then the RFC says that there will be no
charset/language parts.

Note however that this will change the return value for
Message.get_param() in some cases.  For example, whereas before if you
had all unencoded param continuations you would have still gotten a
3-tuple back from this method (with charset and language == None), you
will now get just a string. I don't believe this is a backward
incompatible change though because the documentation for this method
already indicates that either return value is possible and that you
must do an isinstance(val, tuple) check to discriminate between the
two.  (Yeah that API kind of sucks but we can't change /that/ without
breaking code.)

Test cases, some documentation updates, and a NEWS item accompany this
patch.

Original fewer-than-3-parts fix by Tokio Kikuchi.

Resolves SF bug # 1218081.

Also, bump the package version number to 2.5.8 for release.