Don't convert the content-type to lower case in
MimeMessage.getContentType. The content-type may have optional parameters
that are case sensitive (boundary, name).
In removing the lower-case conversion from getContentType, a review was
made for inappropriate case-sensitive comparisons which use data obtained
with getContentType. The only ones found were in isMimeType in both
Message and MimeBodyPart.
Case-sensitive instances of isMimeType were made case-insensitive. Also,
isMimeType was moved from Message to MimeMessage for symmetry with
MimeBodyPart (MimeMessage & MimeBodyPart are similar and contain a good
bit of duplication such as this).
The unit test required fixing now that the case of the boundary text is
preserved.
References:
Commits 2c5186 and dc4002 added the toLowerCase to getContentType in
MimeMessage & MimeBodyPart (Issue 94).
Later, commit 50cd60 removed the toLowerCase addition from MimeBodyPart
(Issue 1289).
Fix the unit test to match.
All line endings in the unit test are now the same.
(Just for consistency. Not a big deal, since such problems are fixed when
the messages are run through EOLConvertingOutputStream.)