Change EML parser/viewer behavior to inline extra txt/html body parts instead of extracting them as attachments

[lfcnassif]

Current (intended) behavior is to take the first html or txt part and inline it as body, extracting all other html/txt parts as attachments. But this is not the behavior used by EML reader applications. We should always respect the Content-Disposition field value (inline or attachment), if it exists. Finally, sometimes the attachment name goes in the Content-Type name field, and not in Content-Disposition filename field. If any of them are populated, I think it is safe to consider the part as attachment, if the disposition field is not inline or if it doesn't exist, there are many eml files not following the specification out there...

[lfcnassif]

A challenge here is inlining together html parts with different encodings, although the most common scenario is a single encoding used by all html parts.

[lfcnassif]

Another detail is that inline images are inlined but also extracted as attachment, this was intentional to display them in the gallery and I think this behavior should be kept.

[lfcnassif]

Reopening this since I detected some email bodies are now being rendered empty.

[lfcnassif]

The issue probably is related to detecting alternative bodies, we should hide just the simpler duplicated version, usually txt.

[lfcnassif]

Closing, seems there was no regression, a very few files (3) are just taking a while to render because they are trying to download Internet resources, what is being blocked by the security manager.