Here's a patch to address this. It includes a fix and tests for three scenarios:
1) setContent() with a text content type without any specific charset. If a charset has been previously set, it is automatically applied to the content type. (This fixes the actual issue.)
2) setContent() with a text content type with a specific charset. The content type charset will override any previously set charset and will change the Email's default charset to itself. (This is current behavior.)
3) setContent() with a non-text content type. Any charset already set in the message will be ignored, since we don't want to declare encodings for binary types. Besides, they'll either come with their own encodings or will be left to the underlying platform. (This is also current behavior, but this ensures that the fix for #1 doesn't inadvertently break other types of content.