Fix ambiguous py::str(kwargs) overload on GCC

[Mohataseem89]

Fixes #5938

GCC reports an ambiguous overload when calling py::str(kwargs) due to
multiple implicit conversions (handle/object)

this PR adds an explicit str(const kwargs&) constructor forwarding to
str(handle), resolving the ambiguity while preserving existing behavior

a small regression test is added to ensure py::str(kwargs) remains
unambiguous across compilers

[Skylion007]

Should the handle ctor below call release instead of ptr for safety?

[Skylion007]

Yuck, it's weird because the handle goes through the raw_str function and steals THAT REFERENCE.

[Mohataseem89]

The intent here was to strictly mirror the existing str(handle) behavior
the new str(const kwargs) constructor only disambiguates overload resolution and forwards directly to the handle-based path without changing ownership semantics

[Mohataseem89]

raw_str() expects a borrowed reference and creates a new string object, so passing ptr() is consistent with how str(handle) already behaves elsewhere in the codebase.
using release() here would transfer ownership and could be unsafe, since kwargs itself does not create a new reference

[rwgk]

Usually we do reviews only after all (or at least most) tests work. Currently basically everything is failing.

[rwgk]

A Cursor-generated solution (along with a test that actually reproduces the issue) is now under PR #5949