refactor: use EmailMessage class

[henryiii]

Make RFC822 a subclass of EmailMessage and remove all reliance on custom behaviors.

Close #101.

[henryiii]

Will need to see if we have anyone using this API, so we know if we need back compat.

[henryiii]

I don't see anyone doing more than bytes and occasionally str, so I think we can drop the old attributes, and bring them back with a deprecation warning if someone needs them.

[henryiii]

Here's the 30 usages I could find:

https://github.com/search?type=code&q=path%3A.py+%28%22import+pyproject_metadata%22+OR+%22from+pyproject_metadata%22%29+NOT+is%3Afork

(Quite a few are actually forks or copies that GitHub doesn't know are forks)

I think dropping .headers and .body is safe, not seeing usages of it, I think it's an internal detail.

[dnicolodi]

Uh? Do we actually need this? Why? Does this even work with EmailMesage? I would not be surprised if it normalized whitespace in headers or encode it somehow. Anyhow, how do multi-line strings end up here?

[henryiii]

It produces the same thing we produce now. It was added in #2, and pretty sure it mostly shows up with multiline summaries:

• Validate that description is single line #30
• revert: validate description #112

I think we could add a warning when one is detected, and then not include the behavior if we can make backward incompatible changes (#140).

[henryiii]

(Note that in #2, the extended mechanism is only for the description, which is now in the body instead, and the actual mechanism included pipe chars).

[henryiii]

(and in scikit-build-core I manually disallow multiline summaries)

[henryiii]

And you can actually read these multiline strings with email.parse, I did check it, it keeps the indention. Without indentation, they don't work, of course.

[henryiii]

I pulled out and merged the preparation steps, so you can see just the move by itself.

[henryiii]

pre-commit.ci autofix