initial migration of the trait bounds to IntoPyObject (PyAnyMethods)

[Icxolu]

This starts the migration of the trait bounds to use IntoPyObject instead of IntoPy/ToPyObject

Test changes:

• datetime changes caused by () now turning into a PyTuple
• bytes changes caused by the specialization
  both are expected by the new API.

I already added a small migration entry here, we can extend that when we migrate more APIs and implemented #4458. Same with the guide section.

Notable observation: Initially I tried to use PyErr: From<T::Error> as a bound on the APIs, but that caused inference issues of the associated type on the call site, so we should probably stick with Into even tho it's a bit more verbose on the implementation site.

[davidhewitt]

Thanks for this! I wonder, we see the A::Error: Into<PyErr> bound so much, should we put that on the trait definition and drop it from everywhere else? At this point it seems to me that any implementation of IntoPyObject which doesn't support Into<PyErr> will be nearly unusable.

[Icxolu]

Yeah, I'm also kind of torn here. Within PyO3 we kind of need this for everything. The only use case I can think of is an error that should specifically not escape into Python and where it might not be possible to move all the error handling into the impl ...

But that sounds like a rather niche use case, so maybe it does not warrant the additional complexity of repeating that bound pretty much everywhere.

[davidhewitt]

The only use case I can think of is an error that should specifically not escape into Python and where it might not be possible to move all the error handling into the impl ...

Right, but how would that IntoPyObject implementation actually be used? A type without that implementation can't be used as a return value from a #[pyfunction], nor as an argument to basically any PyO3 API, nor can most containers containing such a type implement IntoPyObject because of the lack of that bound.

[Icxolu]

Yeah, it could only be used manually on an instance of such a type. I guess there is really no need for that. Moving the bound will make writing generic code much nicer and there is also less surprises for users if they accidentally use an incompatible error type and would get compile error from the macros. I'll make that change and file a PR.