migrate FromPyObject for Bound and Py to new APIs

[davidhewitt]

This PR is two commits which refine FromPyObject for our smart pointers:

• the first adjusts the bound of FromPyObject for both Bound<T> and Py<T> to just be T: PyTypeCheck, while migrating to extract_bound at the same time. This is loosely a follow-up from Add extract_bound method to FromPyObject #3706
• the second implements PyFunctionArgument for &Bound<T>, allowing #[pyfunction] and #[pymethods] to accept &Bound<T>. I think it's desirable to allow this, and it's not possible to implement FromPyObject for &Bound<T> because while the backwards-compatible definition of FromPyObject for the GIL-ref API can't express that lifetime of the reference correctly. In the future we could potentially have FromPyObject<'a, 'py> for &'a Bound<'py, T> if we introduce a second lifetime to FromPyObject.

(I think that second lifetime is necessary if we also wanted FromPyObject<'a, 'py> for Borrowed<'a, 'py, T> too, but I'm less motivated for that and similarly would like to skip adding PyFunctionArgument for Borrowed<T> unless users are reporting it as a useful addition.)

[codspeed-hq]

CodSpeed Performance Report

Merging #3776 will improve performances by 11.44%

_{Comparing davidhewitt:bound-extract (a60c182) with main (d35a6a1)}

Summary

⚡ 1 improvements
✅ 78 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	davidhewitt:bound-extract	Change
⚡	not_a_list_via_downcast	270.6 ns	242.8 ns	+11.44%

[davidhewitt]

I'll push to add some test coverage to this.

[davidhewitt]

Ok, pushed.

[davidhewitt]

Updated this just to add a note to the migration guide about FromPyObject for &Bound<T> not existing right now.

[Icxolu]

The migration looks correct to me (from purely looking at the implementation, i dont have the overview (yet) to see, how this ties into the trait and macro system).
I agree that &Bound should be usable in function and method argument position. I cant see a way of changing FromPyObject in a backwards compatible way, which would allow this implementation, either. So using PyFunctionArgument here seems reasonable to me.

PyFunctionArgument will need the same treatment as FromPyObject, as in introducing extract_bound, but that can also be a separate PR I think.

[davidhewitt]

Thanks! Let's merge this then, and I'll get on with splitting out the rest of the PRs which depend on it.

PyFunctionArgument will need the same treatment as FromPyObject, as in introducing extract_bound, but that can also be a separate PR I think.

As PyFunctionArgument is hidden inside the impl_ submodule I think we can change it without worrying about backwards compatibility. But yes, that's for another PR 👍