Copy list-valued info entries independently in Image.copy() - #9964

The ubuntu-latest Python 3.13 failure is an X11/Xwayland crash in test_qt_image_qapplication, unrelated to this change (it never touches Qt code). Same environmental flake seen on other unrelated PRs in this repo.

I've created lazerg#3 with suggestions for the tests.

Independently re-verified this fix (not affiliated with the PR, filed the original issue):

• Reproduced the bug fresh against unpatched Pillow 12.2.0 for all three cases: Image.copy() on an IM file with two Comment: header lines, rotate(45) (goes through transform()), and Image.copy() on an IPTC file with a duplicate tag (2, 105). All three show is-identity True and a mutation of the copy leaking into the original.
• Applied this PR's diff to a local copy of the installed package and reran the same three repros — all three now show is-identity False and no leak.

_copy_info() centralizing the fix in _new() and transform() matches the root cause exactly (both paths funnel through Image.info construction, not the individual plugins). LGTM from an independent check.

Cherry-picked all three commits from lazerg#3 (e71bb59, 5784152, d9e0e0d), no changes made to them.

• (2, 25) is the better tag. iptc.jpg carries 7 keywords, and Headline is not repeatable per the spec, so the old fixture was testing a tag that would not realistically be a list.
• Calling transform() directly is clearer than reaching it through rotate().
• Agreed that one format is enough; the IM fixture was covering the same code path.

Re-verified the consolidated test still catches both halves of the bug: reverting _copy_info() at _new() and at transform() separately each trips its own assertion. Full local suite passes (4930 passed, 294 skipped, 3 xfailed), black/ruff clean.

Thanks @tritsystem for the independent verification.

Just a note that IM has now been deprecated.