gh-159475: Make parseaddr() reject inline comments in strict mode

[D3e4mlike]

Supersedes #159477, which was accidentally closed and could not be reopened because the branch was force-pushed afterward (a GitHub restriction). The diff and description are otherwise identical.

Fixes #159475.

Summary

email.utils.parseaddr() and getaddresses(), in strict mode (the default
since the CVE-2023-27043 fix), still silently drop a comment that is embedded
inside a dot-atom and splice the surrounding atoms together:

>>> from email.utils import parseaddr
>>> parseaddr('u(comment)ser@d.com', strict=True)
('comment comment', 'user@d.com')

email.headerregistry.Address('u(comment)ser@d.com') rejects this input
(local-part is not dot-atom / quoted-string / obs-local-part), so a caller that
validates or authorizes with parseaddr and then hands the original string to
a strict component gets a subject mismatch — the same class as CVE-2019-11340
(Matrix Sydent) and the motivation behind CVE-2023-27043.

Change

Add an internal _inline_comment flag to the lenient AddrlistClass parser in
Lib/email/_parseaddr.py. It is set when a comment is consumed immediately
before another atom inside an addr-spec (or its domain) — exactly the position
where the comment would be silently dropped and two atoms spliced. In strict
mode, parseaddr / getaddresses now return ('', '') / [('', '')] when
the flag is set.

• Leading and trailing comments remain accepted (they are valid CFWS).
• A comment inside a quoted string remains literal content (not a comment).
• strict=False keeps the historical lenient behavior unchanged.
• Existing strict rejections (domain-literal, multiple addresses, unbalanced
  parentheses) are unchanged.

Why it matters

parseaddr / getaddresses is not deprecated and is still widely used in
security-sensitive paths: CPython's own smtplib, Django, Sentry, Odoo (which
explicitly opts into strict=False), and Ansible all call it. "Legacy" here
means a compat API rather than an abandoned one. The minimal ask is that strict
mode fail closed instead of silently inventing an addr-spec that no strict
reader would accept.

Tests

Added test_parseaddr_inline_comment to Lib/test/test_email/test_email.py,
covering local-part and domain splicing, empty and nested comments,
getaddresses parity, and the still-accepted leading / trailing / quoted cases.

• Issue: email.utils.parseaddr(strict=True) silently splices inline comments in the local-part #159475