Treat trailing lines in multipart parts as significant

[andrewtimberlake]

#207 points out that we are not treating trailing blank lines in multipart emails as significant.
This change changes both the parser and the renderer to treat those correctly.

RFC 2046 §5.1.1

NOTE: The CRLF preceding the boundary delimiter line is conceptually
attached to the boundary so that it is possible to have a part that
does not end with a CRLF (line break). Body parts that must be
considered to end with line breaks, therefore, must have two CRLFs
preceding the boundary delimiter line, the first of which is part of
the preceding body part, and the second of which is part of the
encapsulation boundary.

[tisdall]

I looked at the rest of the PR and it all looks good, but I wasn't sure about this part... Why the additional trimming of trailing CRLF?

This is already in the existing code, but what's the issue with just doing String.split("\r\n") and not trimming the end of each line? Thus keeping all the encoded content.

[tisdall]

I see the 2nd trim_trailing is related to a test case (test "parse invalid date in Received header"), so I guess that needs to stay. And I guess the first one is to remove an issue with a trailing empty value(s) after the split?