rust-pyo3: exposition of AncestorsIterator Compared to the early experiments, we have one less `RwLock` in the wrapping. Still that is somewhat redundant with `UnsafePyLeaked` being itself some kind of lock. In the original rust-cpython code, we were borrowing the `RefCell` with a method that can panic. Instead we are now converting the `PoisonError` that unlocking a `RwLock` can produce. Since all methods acquiring the `RwLock` are themselves protected by the GIL and do not release it before returning, nor do they leak RwLock guards, there is no risk of contention on these locks themselves.

rust-pyo3: generic borrows of UnsafePyLeaked with error treatment Maybe we will find later a more pleasant way to express safety. Meanwhile, these helpers are useful because of the proper error propagation, and will help to avoid too much cruft in the caller code.

rust-pyo3: error propagation for UnsafePyLeaked wrapping a result This `py_leaked_or_map_err` is the PyO3 version of the function of the same name in `hg-cpython/src/ancestors.rs`.

rust-pyo3: getting rust-cpython GIL handle from various PyO3 objects Depending on the caller context, we might have a `Python<'py>` around or any of the smart pointers that bear the GIL lifetime. Of course, all of these can give back a `Python<'py>` but it is worthwile to reduce the needed boilerplate. The trait just expresses that a lifetime is assumed to be outlived by the PyO3 GIL lifetime. It is marked as unsafe because that is just trusting the implementor. A first version of this was made of a safe trait with a `get_py()` method and the corresponding trivial implementations. We found it finally to be even more artificial, as it boils down to coding 4 functions doing and returning no real data, that we hope the compiler will optimize away.

rust-pyo3: intermediate ProxyIndex extraction Retrieving the `UnsafePyLeaked` without borrowing it will be necessary for the upcoming classes that need to store an inner object derived from it.

rhg: set group-writable checkisexec file permissions in Python This actually achieves what the parent commit tried to do, but on the Python side. Unfortunately, `mkstemp` doesn't seem to let us specify the initial file permissions so we have to apply umask by hand when chmodding.

rhg: set the expected temp file permissions (0o666 minus umask) This continues the theme of a48c688d3e80, and fixes the bug #6375, which was causing some problems for us, where a non-group-readable file can't be copied, which breaks some tools that copy the repo. This affects both the `checkexec` file and the temporary file we use for filesystem time measurement, since either of these files remaining on disk can cause this problem, and the 0666 permissions are just the better default here.

rhg: add a collision detection to complain about duplicated commands The previous commit made it easier (too easy) to define commands with identical names. It turns out `clap` does nothing to detect such collisions, which also leads to very confusing behavior. This change catches that error, and reports where the commands came from.

rhg: consistently use the command name given in clap::command!(<...>) macro Before this patch there are 2 things the user controls: 1. the module/command name, specified in subcommand! macro 2. the command name, specified in clap::command! macro If these are out of sync, we get no compile error or a clear runtime error, but instead a confusing behavior where command line parser parses one thing, but running it doesn't work. This commit makes the clap::command! macro the sole authority determining the command name, so we don't have to worry about this weird behavior any more. It also makes it easy to validate agreement between (1) and (2) if we want it, but I didn't add the check because I'm not sure people necessarily want it.

rhg: simplify the subcommands macro Reduce the scope of the macro to only generate individual `SubCommand` values. This way, it will be easy to tweak the behavior of `add_subcommand_args` and `subcommand_run_fn` without having to understand the details of the macro. It also lets us easy add commands that don't fit the idiom, for example the "admin::" commands or "script::" commands.