obsstore: `create` method return True if a marker is actually added

The obsstore method now have a return value. This informs caller about the
actual creation of a new markers. No new markers are created if it would have
been a duplicate.
obsstore: add a __len__ method

We can already use "for mark in store:" it make sense to allow
"len(store)" too.
revset: changed lazyset __add__ implementation to work lazily

Performance Benchmarking:

$ time hg log -qr "first(author(mpm) or branch(default))"
0:9117c6561b0b

real  0m3.875s
user  0m3.818s
sys 0m0.051s

$ time ./hg log -qr "first(author(mpm) or branch(default))"
0:9117c6561b0b

real  0m0.213s
user  0m0.174s
sys 0m0.038s
revset: changed spanset __add__ implementation to work lazily

$ time hg log -qr "first(0:tip or draft())"
...

real  0m1.032s
user  0m0.841s
sys 0m0.179s

$ time ./hg log -qr "first(0:tip or draft())"
...

real  0m0.378s
user  0m0.291s
sys 0m0.085s
merge: move merge state file path into a constant

We are about to change the format. Having the file path in a single place make
it easier to update the filename for the new version.

--HG--
branch : stable
merge: change the merge state serialisation to use a record based logic

The format of the file is unchanged. But we are preparing a new file with a new
format that would be record based. So we change all the read/write logic to
handle a list of record until a very low level. This will allow simple plugging
of the new format in the current code.

--HG--
branch : stable
merge: introduce new format for the state file

This new format will allow us to address common bugs while doing special merge
(graft, backout, rebase…) and record user choice during conflict resolution.

The format is open so we can add more record for future usage.

This file still store hexified version of node to help human willing to debug
it by hand. The overhead or oversize are not expected be an issue.

The old format is still used. It will be written to disk along side the newer
format. And at parse time we detect if the data from old version of the
mergestate are different from the one in the new version file. If its the same,
both have most likely be written at the same time and you can trust the extra
data from the new file. If it differs, the old file have been written by an
older version of mercurial that did not knew about the new file. In that case we
use the content of the old file.

--HG--
branch : stable
merge: record the "other" node in merge state

We need to record the merge we were merging with. This solve multiple
bug with resolve when dropping the second parent after a merge. This
happen a lot when doing special merge (overriding the ancestor).
Backout, shelve, rebase, etc. can takes advantage of it.

This changeset just add the information in the merge state. We'll use it in the
resolve process in a later changeset.

--HG--
branch : stable
merge: infer the "other" changeset when falling back to v1 format

When we have to fallback to the old version of the file, we infer the
"other" from current working directory parent. The same way it is currently done
in the resolve command. This is know to have shortcoming… but we cannot do
better from the data contained in the old file format. This is actually the
motivation to add this new file format.

--HG--
branch : stable
merge: add "other" file node in the merge state file

This data is mostly redundant with the "other" changeset node (+ other changeset
file path). However, more data never hurt.

The old format do not store it so this require some dancing to add and remove it
on demand.

--HG--
branch : stable
extra : amend_source : 144da04e706dc03eb97d19cf4aea42f28cf3841b
resolve: use "other" changeset from merge state (issue4163)

We can use the "other" data from the recorded merge state instead of inferring
what the other could be from working copy parent. This will allow resolve to
fulfil its duty even when the second parent have been dropped.

Most direct benefit is fixing a regression in backout.

--HG--
branch : stable
extra : rebase_source : 4154ac837e4a0b36e24022f267f615f856a91499
merge with stable