pull: move `fetch` subset into the object Tree discovey use a `fetch` variable to know what is being pulled. We move this information in the `pulloperation` object. This make it possible to extract the changeset pulling logic into its own function.

pull: make pulled subset a propertycache of the pull object The computation of the subset is simple operation using two useful pull information (1) the set of common changeset before the pull (2) the set of pulled changeset. We move this data into the `pulloperation` object since some phase will need them. And we turn the pulled subset computation behind a property case as multiple pull phase will need it.

pull: move phases synchronisation in its own function Now that every necessary information is held in the `pulloperation` object, we can finally extract the phase synchronisation phase to it's own function. This changeset is pure code movement only.

pull: move pulled subset into the object We compute the set of local changeset that were target of the pull. This is then used by phases logic to decide which part of the history should have it phase updated. We move this information into the object to allow extraction of phase synchronisation in its own function. I expect obsolete marker exchange to use it too in the future.

revset: added operations to spanset to duck type baseset Added more operations which are not lazy but only used so far to duck type baseset.

revset: added basic operations to spanset Added methods __add__, __sub__ and __and__ to duck type more methods in baseset

revset: added spanset class to represent revision ranges

revset: added lazyset implementation to extra revset

revset: added lazyset implementation to converted revset

revset: added lazyset implementation to closed revset

push: feed pulloperation object to _pullobsolete function We now have all necessary information in the `pulloperation` object itself.

pull: move transaction logic into the pull object Most local change that occurs during a pull are doing within a `transaction`. Currently this mean (1) adding new changeset (2) adding obsolescence markers. We want the two operations to be done in the same transaction. However we do not want to create a transaction if nothing is added to the repo. Creating an empty transaction would drop the previous transaction data and confuse tool and people who are still using rollback. So the current pull code has some logic to create and handle this transaction on demand. We are moving this logic in to the `pulloperation` object itself to simplify this lazy creation logic through all different par of the push. Note that, in the future, other part of pull (phases, bookmark) will probably want to be part of the transaction too.

pull: move obsolescence marker exchange in the exchange module The obsolescence marker exchange code was already extracted during a previous cycle. We are moving the extracted functio in this module. This function will read and write data in the `pulloperation` object and I prefer to have all core function collaborating through this object in the same place. This changeset is pure code movement only. Code change for direct consumption of the `pulloperation` object will come later.

pull: move `force` argument into pull object One more step toward a more modular pulh function.

pull: move `heads` argument into pull object One more step toward a more modular pull function.

pull: move `remote` argument into pull object One more step toward a more modular pull function.