repo-config: clarify why we seems to parse the repository "twice" That is not the first time I am confused about this code, lets add a comment to save time in the future.

config: type `rcutil` It helps to understand what is going on here and catch future errors.

config: extra the code showing config in its own module too This conclude our extract of the main semantic in a dedicated module.

config: move "component display" in the new module That part seems dubious, but at least it is now isolated. I added inline comment about how "suboptimal" it is.

config: move edition code in its own module We start to move code related to the command outside of the main commands modules for clarity. This also highlight some flaw in this code and the new flag are missing some error handling. However we will deal with them later. This move removes the needs for a few module import in the `commands.py` which I see as a good sign.

config: move `rcutil` module under a new `mercurial.configuration` module This new module aims at gathering configuration related code, rcutil definitely deserves to live there.

rust-pyo3: plugging in the dagop module We refrain from removing its counterpart in `hg-cpython`, so that comparisons can easily be made.

rust-pyo3: simplified API to get core Index references Given the amount of conversion and arcane internal detail, it is easier for the caller and makes a better separation of concerns to just introduce a new unsafe helper. It is actually possible that it would be safe, and we can decide about that later. Actually the reason given in the `cpython` crate for unsafety of the `try_borrow()` method is the following: ``` // try_borrow() and try_borrow_mut() are unsafe because self.data may // have a function returning the inner &'static reference. // If T is &'static U, its lifetime can be easily coerced to &'a U, but // how could we do that for Whatever<'static> in general? ``` Given that we coerce the Index reference to the GIL lifetime and that it is unlikely that the inner data would contain a function returning the a `'static` reference, it is possible that it is actually even safe.

rust-pyo3: dagop submodule implementation This is the first demonstration that the passing of objects through the Python interpreter from `rustext` to `pyo3_rustext` actually works. In the Python tests, we conflate the presence of the `pyo3_rustext` package with that of `rustext`, as we do not plan to support building one and not the other (we hope to convert fully to PyO3 soon). The skipping is actually done by the base test class. The implementation of `rank` is as trivial as it was in `hg-cpython`, yet it required to be able to convert exceptions from `vcsgraph`.

rust-pyo3: conversions to GraphError Python exception The nice thing is that with PyO3, exceptions can be instantiated without holding the GIL. Hence the only thing that prevents us to implement `Into<PyErr>` for `hg::GraphError` is that neither is defined by the current crate. We could use a wrapping "newtype", but the compiler is not so clever yet that it could chain automatically to two needed `into()`, so we'll end up with some type conversion anyway, involving something like `GraphErrorWrapper`. At this point, explicitly named methods are just simpler.