negative-to-unsigned conversions are inconsistent between `ValueError` and `OverflowError`

The following test fails inconsistently on various Python versions. See also https://github.com/PyO3/pyo3/pull/6016#discussion_r3230711385

diff --git a/src/conversions/std/num.rs b/src/conversions/std/num.rs
index 2fca7aa9f..207249246 100644
--- a/src/conversions/std/num.rs
+++ b/src/conversions/std/num.rs
@@ -920,6 +920,17 @@ mod tests {
                     let obj = val.into_pyobject(py).unwrap();
                     assert_eq!(obj.extract::<$t>().unwrap(), val as $t);});
                 }
+
+                #[test]
+                fn test_negative() {
+                    Python::attach(|py| {
+                        let obj = py.eval(c"-1", None, None).unwrap();
+                        match obj.extract::<$t>() {
+                            Ok(val) => assert_eq!(val, <$t>::try_from(-1i8).unwrap()),
+                            Err(err) => assert!(err.is_instance_of::<exceptions::PyValueError>(py)),
+                        };
+                    });
+                }
             }
         )
     );

Note that older CPython APIs such as PyLong_AsUnsignedLong use OverflowError, and newer APIs such as PyLong_AsUInt64 use ValueError.

I think we should match the convention of the newer CPython APIs and use ValueError as the error message. However there is possibly an argument that we should instead accept this divergence and have a clean split between (say) 3.14+ using ValueError and older versions using OverflowError.

See also #5179 which is related here.

Start in src/conversions/std/num.rs and review the negative-value extraction test shown in the issue, then read the linked pull request discussion and related issue #5179. Compare the relevant older and newer CPython conversion APIs; done means the project’s chosen ValueError or OverflowError convention is applied consistently and the test passes across supported Python versions.