pull: introduce a pulloperation object

This object will hold all data and state gathered through the pull. This will
allow us to split the long function into multiple small one. Smaller function
will be easier to maintains and wrap.  The idea is to blindly store all
information related to the pull in this object so that each step and extension
can use them if necessary.

We start by putting the `repo` variable in the object. More migration in other
function.
pull: move `remote` argument into pull object

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

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

One more step toward a more modular pulh function.
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 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.
push: feed pulloperation object to _pullobsolete function

We now have all necessary information in the `pulloperation` object itself.