peer: have a common constructor and use it For now it does not do much, but we will extend it to also store a path object soon.

peer: use a dedicated name for the `peer` constructor We want to change the argument it takes, so we rather make them different function.

peer: dissolve `_peerlookup` into its last two callers This is about to need more changes and the function won't be useful. We do it early to clarify later changes.

peer: stop having a `peer()` method on `peer()` This is already a peer, why do you want a peer if you already have one.

clone: explicitly detect the need to fetch a peer Instead of having `peer()` method on all `peer()` for this usecase, we could simply handle it explicitly.

addbranchrevs: explicitly detect the need to fetch a peer Instead of having `peer()` method on all `peer()` for this usecase, we could simply handle it explicitly.

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

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).