`PyErr::new` has surprising edge cases

[davidhewitt]

Continuing from #4400, where we observed that a tuple was being flattened as part of a call to PyErr::new.

The other special case is that PyErr::new(py.None()) counts as no arguments.

#[pyo3::pymodule]
mod pyo3_scratch {
    use pyo3::prelude::*;

    #[pyfunction]
    fn bug(py: Python<'_>) -> PyResult<()> {
        Err(pyo3::exceptions::PyValueError::new_err(py.None()))
    }
}

>>> try:
...     pyo3_scratch.bug()
... except ValueError as e:
...     print(e.args)
... 
()

Again if we wrap the py.None() in a tuple as (py.None(),) then the final e.args will be (None,).

I'm open to debating whether we should change PyErr::new, because this doesn't match Python users' instincts, where there is no special case:

>>> print(ValueError(None).args)
(None,)
>>> print(ValueError((1,)).args)
((1,),)

[zdevito]

Just chiming in to say that I hit a very similar bug to #4400 because I wrote PyStopIteration::new_err(obj) and if obj were a tuple it would slice off and return the first argument as the value. This behavior feels inconsistent with the .call and .call1 family of functions which require a tuple. When it compiles, it really makes the user think that :new_err is suppose to accept a single argument for an exception class. Perhaps making :new_err always do the single argument case, and having a :new_unpack(..) that always required a tuple would be clearer.