Use Arbitrary Self Types instead of Py<Type>Methods traits

[LilyAcorn]

For #4869.

I removed the Deref implementation for Bound<'py, T> because it conflicts with any implementation of std::ops::Receiver we need to use Arbitrary Self Types. For example:

error[E0119]: conflicting implementations of trait `std::ops::Receiver` for type `instance::Bound<'_, PyBool>`
  --> src/types/boolobject.rs:27:1
   |
27 | impl std::ops::Receiver for Bound<'_, PyBool> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<P, T> std::ops::Receiver for P
             where <P as Deref>::Target == T, P: Deref, P: ?Sized, T: ?Sized;

I also added an implementation of PyAnyMethods for Bound<'py, T> to compensate for the removal of Deref. To get this working, I dropped the requirement that PyAnyMethods can only be implemented for sealed types. An alternative approach I think would be to just remove Deref and require .as_any() or .into_any() calls in more places.

After all of this, clippy passes on nightly on my machine (with the exception of one lint, which I think is unrelated to this PR). I can also run much of the test suite, but get an error in #[pyclass] which I currently don't understand:

error[E0599]: no method named `as_type_ptr` found for reference `&pyo3::Bound<'_, PyType>` in the current scope
 --> tests/test_field_cfg.rs:5:1
  |
5 | #[pyclass]
  | ^^^^^^^^^^
  |
  = note: this error originates in the attribute macro `pyclass` (in Nightly builds, run with -Z macro-backtrace for more info)
help: there is a method `as_ptr` with a similar name
  |
5 | as_ptr
  |

I'm confident this is coming from

pyo3/pyo3-macros-backend/src/pyclass.rs

Line 1834 in 29c64d8

.as_type_ptr()

but I see no reason why the .as_type_ptr method shouldn't be found, since it's implemented in

pyo3/src/types/typeobject.rs

Lines 51 to 54 in 29c64d8

	#[inline]
	pub fn as_type_ptr(self: &Bound<'py, Self>) -> *mut ffi::PyTypeObject {
	self.as_ptr() as *mut ffi::PyTypeObject
	}

[davidhewitt]

Thanks very much for running with this! I haven't managed to read in detail, can you summarise how it feels to use? I see there's a fair bit of path syntax change, that's unexpected to me.

Do you think we should be proceeding down this road? Does it seem like it's something fundamental with our design that's wrong? Or something in the self types feature which we should flag upstream before it stabilizes?

[LilyAcorn]

Thanks very much for running with this! I haven't managed to read in detail, can you summarise how it feels to use? I see there's a fair bit of path syntax change, that's unexpected to me.

Currently I think there's some rough edges. The existing Deref implementation for Bound<'py, T> to Bound<'py, PyAny> is incompatible with the required std::ops::Receiver implementation(s), which leads to a lot of knock-on changes required. In addition, there's the path syntax changes - I hope that these are only required due to a bug in the not yet stabilized Arbitrary Self Types implementation, but I haven't yet verified this.

Do you think we should be proceeding down this road? Does it seem like it's something fundamental with our design that's wrong? Or something in the self types feature which we should flag upstream before it stabilizes?

I'm currently experimenting with some alternative designs to see what level of churn they cause. Once I've finished with those, I'll have a better idea. But unless these other designs work much better, I think we'll need to flag to upstream.

[LilyAcorn]

I now think this is very workable. We'll need to decide how best to handle the loss of Deref, but I think there's a few reasonable options we can consider.