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

[LilyFoote]

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?

[davidhewitt]

There's a lot of these changes to use path syntax, why?