restrict IntoPyObject::Error to convert into PyErr

[Icxolu]

This restricts the error type of IntoPyObject to be convertible into PyErr. While not strictly necessary this makes writing generic code much nicer, because we don't need to repeat a bound on the associated type all the time. It's also potentially less surprising to users because the error with an incompatible error will occur at implementation site instead of usage site. The usage without this bound are extremely limited, since the macros and nearly all the PyO3 API and containers require it, so it could only be called manually anyway.

XRef: #4480 (review)

[davidhewitt]

Overall looks great, thanks! A couple of brief thoughts, which might be better for follow ups...

[davidhewitt]

I wonder if there's value in having a trait like

trait IntoPyObjectExt<'py>: IntoPyObject<'py> {
    fn try_into_pyobject(self, py: Python<'py>) -> PyResult<Self::Output>;
    fn try_into_pyobject_any(self, py: Python<'py>) -> PyResult<Bound<'py, PyAny>>;
}

... which is sealed and has a single blanket impl for all T: IntoPyObject.

I don't know if I like those exact names, but the point is there's a lot of repeated patterns which I see us using (and I think users might experience the same).

We could make the trait crate-private in the short term while we figure out what feels good.

[Icxolu]

Interesting thought, we can definitely experiment with that. But this is really only effects generic code. Normal user code can usually just use the ?, because they get a concrete type and all PyAnyMethods are accessible via Deref

[davidhewitt]

Agreed, though I think we have a lot of generic code internally and I think users probably do write generic code from time to time, so it'd be nice to have a long term solution to make it easier.

Also I wonder if having such methods will help keep generic code bloat down by reusing common chunks, but that's just speculation until measured.

Either way, no need to block merge on this.