Charset attribute can be out-of-sync with actual encoding after decoding to utf8
The charset can be declared in the html itself and can fall out of sync when the body part is decoded to utf8. The html returned from this library will then be erroneously displayed when given to a browser.
Content-Type: multipart/alternative;
boundary="_000_965A26A6D93540AD9522027B9387AAACXXX_"
--_000_965A26A6D93540AD9522027B9387AAACXXX_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
=97
--_000_965A26A6D93540AD9522027B9387AAACXXX_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body dir=3D"auto">
=97
</body>
</html>
--_000_965A26A6D93540AD9522027B9387AAACXXX_--
This is a list of all the cases we can come up with, there may be more.
<meta charset=Windows-1252><meta charset="Windows-1252"><meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"><meta http-equiv="Content-Type" content="text/html; charset="Windows-1252"">
It may be easier to just remove everything that matches <meta [^<>]*charset[^<>]*>.
This could be added as a helper function. Scanning/removing charset definitions from HTML should not be done by default for performance reasons.
Would you accept a breaking change that changes PartType::Html(Cow<'x, str>) to PartType::Html(Html<'x>) such that the str may only be accessed with an appropriately named method? Currently this is a footgun, as I presume most users will expect html to mean it is ready to consume by a browser.