scmutil: accept multiple predecessors in 'replacements' (API) This changeset makes 'cleanupnodes' accepts multiple predecessors as `replacements` keys. The same as it accepts multiple successors as `replacements` values. To avoid breaking all callers, the old and new ways are currently valid at the same time. We'll deprecate and drop the old way later. This change is the first step toward a better tracking of "fold" event in the evolution history. While working on the "rewind" command (in the evolve extension), we realized that first class tracking of folds are necessary. We already have good tracking of splits. When walking the evolution history from predecessors to successors, that makes for a clear distinction between having multiple successors because of the actual splitting of a changeset or content-divergences. The "rewind" command allows restoring older evolution of a stack of changesets. One of its mode walks the evolution history to automatically find appropriate predecessors. This means walking from successors to predecessors. In this case, we need to be able to make the same distinction between an actual fold and other cases. So we will have to track folds explicitly. This changesets only focus on making it possible to express fold at the `cleanupnodes` API level. The actual tracking will be implemented later.

scmutil: expand long "one-liner" When a one-liner gets 3 lines longs, it loses its expressivity benefits. We expand it into a simple for loop. This makes future changes of the code in that area clearer.

shelve: find shelvedctx from bundle even if they are already in the repo We use the new "duplicates" node tracking to find the tip of the bundle even if it already exists in the repository. Such logic is not supposed to be needed in theory. If the shelve was made using internal-phase, we already know its node. Otherwise, the bundle content should have been stripped. However, handling it makes the shelve code more robust and provide a good example of "revduplicates" usage.

shelve: return the shelved node as part of bundle application It make sense to have the function in charge of unbundling the shelved revision also return the node of that revision (when the data is in the bundle). This will help us to handle unnatural state where the unshelved change already exists in the repository.

changelog: keep track of duplicated node in the transaction adding them The transaction is already tracking the new nodes. We now tracks the "duplicates" in the same location.

revlog: add a callback "tracking" duplicate node addition If a changegroup contains node already added to the repository, they will be skipped. Skipping them is the right behavior (we don't need to store things twice), but it can hide some information to the code doing the unbundle (eg: shelve looking for the tip of the bundle). The first step to improve this situation is to add a low level callback. We do not need this tracking on all revlog, so actual tracking will be added in the next changeset.

logtoprocess: define $HG for children processes So they can compute the hg version for instance. Differential Revision: https://phab.mercurial-scm.org/D4768

py3: mask out None type when printing in `debuglocks` Apparently, %b doesn't allow None.

py3: ensure standard exceptions use `str` type strings in windows.py See also edaa40dc5fe5.

py3: replace a StandardError reference This doesn't exist on py3, and the standard way of handling this seems to be to catch both exceptions.