Git::Lib#commit_data currently produces a malformed data hash for a
commit containing a gitsig header field, with the majority of the PGP
signature being considered part of the message.

I'd like to fix this, so this introduces a new example repo with a
single signed commit in it.

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

Git::Lib#commit_data currently misparses commits containing a multiline
gpgsig header, extracting only the first line as the gpgsig entry, and
considering the rest of the key part of the commit message.

Per the git docs[1] the gpgsig header is used to give the GPG signature
of a signed commit, with continuation lines denoted by a leading space:

    tree eebfed94e75e7760540d1485c740902590a00332
    parent 04b871796dc0420f8e7561a895b52484b701d51a
    author A U Thor <author@example.com> 1465981137 +0000
    committer C O Mitter <committer@example.com> 1465981137 +0000
    gpgsig -----BEGIN PGP SIGNATURE-----
     Version: GnuPG v1
     $
     iQEcBAABAgAGBQJXYRjRAAoJEGEJLoW3InGJ3IwIAIY4SA6GxY3BjL60YyvsJPh/
     HRCJwH+w7wt3Yc/9/bW2F+gF72kdHOOs2jfv+OZhq0q4OAN6fvVSczISY/82LpS7
     DVdMQj2/YcHDT4xrDNBnXnviDO9G7am/9OE77kEbXrp7QPxvhjkicHNwy2rEflAA
     zn075rtEERDHr8nRYiDh8eVrefSO7D+bdQ7gv+7GsYMsd2auJWi1dHOSfTr9HIF4
     HJhWXT9d2f8W+diRYXGh4X0wYiGg6na/soXc+vdtDYBzIxanRqjg8jCAeo1eOTk1
     EdTwhcTZlI0x5pvJ3H0+4hA2jtldVtmPM4OTB0cTrEWBad7XV6YgiyuII73Ve3I=
     =jKHM
     -----END PGP SIGNATURE-----

    signed commit

    signed commit message body

This commit adds a test and a special parsing case for the gpgsig header
to accommodate this.

[1] https://git-scm.com/docs/gitformat-signature#_commit_signatures

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

In the previous commit I introduced a new case for git commit header
parsing to cover the gpgsig header, which supports multi-line values.

I think the #process_commit_data method is getting a bit unwieldy, so
this commit extracts the generic header parsing, separating it from the
special-case handling of parent (which is not multi-line, but can have
multiple entries and thus multiple values).

By switching to a regex key/value extraction approach we're also able to
avoid splitting the entire string before re-joining the value.

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

The general format of `git cat-file tag` output is identical to that of
`git cat-file commit`, so we can use the generic parsing helper.

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

These methods always explicitly set the 'message' key of the output hash
based on the `git cat-file` output, so we don't need a default in the
starting hash.

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

This was introduced in [1] to handle variance in indentation when
parsing commit messages; at the time the #process_commit_data method had
two callers, one which used it to process log lines, and the other which
used it to process the output of `git cat-file commit <SHA>`. The former
sees a 4-space indent, the latter, zero.

Since [2], however, the log processing has been handled by
the #process_commit_log_data method, so #process_commit_data exclusively
handles un-indented inputs, and we can remove the indent parameter.

[1] ruby-git@05117d4
[2] ruby-git@97e1fff

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

As with the previous commit, this default value was relevant when this
method was also used to process git log output. It no longer is, and its
only caller passes the sha value, so we can remove the default.

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>

As with the previous commits, this indent parameter appears to be a
relic of old usage; the #process_tag_data method has a single caller
that explicitly sets the indent to zero, so the indent parameter and
associated handling can just be removed.

Signed-off-by: Simon Coffey <simon.coffey@futurelearn.com>