It's time to take a stab at patch versioning. This commit will parse
patches sent as replies to a previous patch (either a direct reply or
somewhere in the subtree spawn by a patch) and create a new revision to
reflect that the Series has been updated.

Turns out it's not entirely trivial. We basically need to do a similar
threading a MUA would do.

For instance, we can't purely rely on the references header, because
patches sent with git send-email don't have the full path to the root
mail in references, but just the parent mail (that's because git
send-email patches have no way to know the full context of the thread
they are sent as a reply to).

So, here again, unit testing comes to the rescue. I'm careful to have
basic coverage of all cases I'm interested in. Of course, one can extend
the number of cases recognised if needed.

A word on versioning. The parsing doesn't actually look at the "v2",
"v3" indicators on patches. The main reason for that is that the series
revision is global to a series, ie. if a series has 10 patches, patch 4
and 7 have both v2 versions sent as replies to the thread, the global
series version will be 3 (v1: original series, v2: v1 + patch 4 v2, v3:
v2 + patch 7 v2). That scheme has a benefit: it doesn't rely on the
using getting the numbering right.

v2: Fix parsing of headers from the db by using HeaderParser
v3: Fix a corner case when the version n of a patch is sent as a reply
    to version n - 2 instead of n - 1
v4: Fix a corner case where the user doesn't resend the series marker
    (ie 2/2) when sending a new version of a patch that is part of a
    series
v5: Rebase on top of the SERIES_DEFAULT_NAME change

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>