soundness fix: retain PyBuffer while using the &[u8] that comes from it

[oconnor663]

Previously we were getting a slice from a PyBuffer and then letting that PyBuffer drop. That released our "lock" on the buffer, which meant other threads could potentially race to resize it and turn our reads into use-after-free bugs. Refactor things so that the slice is lifetime-bound to the PyBuffer that protects it.

Also, previously I was calling PyBuffer::as_slice to take advantage of the internal contiguity check that it does, but that required disassembling and reassembling the raw slice to cast away ReadOnlyCell. Now I think it's cleaner to do the contiguity check explicitly and then work directly with the raw buffer pointer.

While cleaning up the comments around this, I realized I had previously misunderstood how Python::detach works. I thought it didn't allow certain lifetimes to pass into the closure (similar to std::thread::scope), but in fact it basically just requires Send. Casting away the PyBuffer::as_slice lifetime isn't really relevant; what matters is that &[u8] is Send while &[ReadOnlyCell<T>] isn't. That raised some questions about how all this interacts with freethreaded builds, where we never have a GIL protecting us. I've revised some of the big comments and also opened a discussion thread here: PyO3/pyo3#5508

[ddelange]

I love the deep dive, and the PR description is next level. LGTM 👍

[ddelange]

this reminds me of ABI3 (limited API). I think we can't use it here because of the low level buffer stuff, but AB3 wheels would be awesome of course because they're forward compatible (future python minor version bumps, or even major version bumps?)