rust-pyo3: initial port of PySharedRef At this point, we have a full translation, with some tests. The tests are high level, demonstrating the case of iterating over `HashSet` as a doctest. The assertions are written as Python statements, in order not to be obscure and to resist later refactorings. The rust-cpython integration tests will be ported in a subsequent changeset. We find the example of iterating over `HashSet` to be more convincing than the iterating over `Vec`, the example provided in rust-cpython, because in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and an index. This would of course be reimplementing the iterator, but is simple enough that it leads the reader to believe that having a reference is the problem, whereas the problem is having a reference that is itself enclosed in a type with lifetime that can be arbitrary complex. It took us some time to remember that subtlety, and hence we reworded the documentation to stress that point. We decided to put this work a separate crate, which makes running `cargo test` work for the crate, but not for the entire workspace: the `extension-module` feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as default and run the tests with `--no-default-feature` in Makefile, hence in CI. An important difference with rust-cpython is that everything has to be `Sync`, hence we replace `RefCell` with `RwLock` and only speak of "interior mutability" in the documentation. Since everything happens in `hg-pyo3` behind the GIL, there is at this point no reason to use `read()` and `write()` instead of respectively `try_read()` and `try_write()`. But PyO3 is aiming to support free-threaded Python (without GIL), and `PySharedRef` should therefore allow waiting for its inner locks.