gh-158146: Test keyword arguments to warnings.warn_explicit

[seanabreau]

Closes #158146.

Test that warnings.warn_explicit() accepts its four required parameters by position or keyword, for both string messages and warning instances. Placing the test in WarnTests exercises the C and pure-Python implementations and verifies the emitted warning's message, category, filename, and line number.

pytest's Node.warn() relies on this calling convention. The test was prompted by RustPython #8814; CPython's existing behavior is unchanged.

Validation on a macOS debug build of CPython main (80f9aa0):

• Both new CWarnTests and PyWarnTests cases pass.
• ./python.exe -m test test_warnings: success, 199 tests run, 6 skipped.
• ./python.exe -m test test_warnings -m '*test_warn_explicit_keyword_args' -R 3:3: passes without leaks in the measured repetitions.
• make patchcheck and configured pre-commit checks pass. No NEWS entry is needed for a test-only change.

The same test method also catches the original RustPython bug (eight failing keyword-call subtests) and passes with RustPython #8814 applied.

AI assistance: Codex prepared the test and PR description and ran validation.

• Issue: Add coverage for keyword arguments to warnings.warn_explicit #158146

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[aisk]

Personally I think testing every combination of the arguments this way is a little too complex and implicit.

Maybe testing the most meaningful combinations is a better choice? I'm not sure about this, so maybe we can wait for other reviewers' opinions.

[StanFromIreland]

Sorry, but I'm going to close this. We generally don't specifically test such things (it's usually covered implicitly by other tests), and this test seems a little overkill.