path: use `get_clone_path_obj` in share The return is simpler to use, and this mean less user for the old function. We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in mq We directly use the `path` object to build the `peer` object. There is one case where we don't. We should fix that at the same time as we fix the sub-repo cases.

path: use `get_clone_path_obj` in _getlocal We don't need to feed the `path` object to a `peer` object, but using an higher level function is simpler here (e.g. no subscript access, explicit attribute access).

path: pass `path` to `peer` in `hg init` We directly use the `path` object to build the `peer` object.

path: add a `get_clone_path_obj` function Same logic as the `get_unique_pull_path_obj` function, this give access to the `path` object directly.

path: simplify the implementation of `get_clone_path` We can simply use the logic from `get_unique_pull_path_obj` now.

path: clarify document of `get_clone_path` This return a url as `bytes`, not a `path` object.

path: pass `path` to `peer` in `hg perf::discovery` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in remotefilelog's tests We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg fastannotate` We directly use the `path` object to build the `peer` object.