bundle2: record processing results in the bundleoperation object Part handlers can now add records to the `bundleoperation` object. This can be used to help other parts or to let the caller of the unbundling process react to the results.

bundle2: introduce a bundleoperation object This object will hold all data and state gathered through the processing of a bundle. This will allow: - each handler to be aware of the things unbundled so far - the caller to retrieve data about the execution - bear useful object and logic (like repo, transaction) - bear possible bundle2 reply triggered by the unbundling. For now the object is very simple but it will grow at the same time as the bundle2 implementation.

bundle2: feed a unbundle20 to the `processbundle` function The unbundle can comes from multiple sources. (on disk file, peer, etc) and (ultimately) of multiple type (bundle10, bundle20). The `processbundle` is no longer in charge of creating the bundle.

bundle2: lock the repo during unbundle test We forgot the lock the repo. It's not too bad during tests, but the lock also still carry some transaction logic. (yes we need to get rid of this)

merge: keep destination filename as key in filemerge actions Gives more readable debug output and makes it possible to compare/merge actions later.

merge: keep destination filename as key in actions for merge with dir rename Avoids None: local renamed directory to b/c -> d updating:None 1/1 files (100.00%) and makes it possible to compare/merge actions later.

merge: include ancestor node in merge actions

merge with stable

repoview: use _gethiddenblockers in computehidden No functionality has changed, since we've only extracted the code into its own function. Now extensions can wrap _gethiddenblockers to provide their own blocker without polluting bookmarks or local tags.

repoview: add _gethiddenblockers method This is a standalone function that will provide the ability for extensions to wrap.