plumbing: fix signature with > before < parsing

[mcuadros]

This is a fix for issue: #202

Since the fullname is free text, given a foo> the result was a panic, now this is handled properly returning foo> as the fullname. Another extra security guards was added to protect the function against malformed signatures.

[ajnavarro]

If the email address is crap, this crap will be extended to the committer name:

`Foo Bar <foo>@bar.com>`: {
	Name:  "Foo Bar",
	Email: "foo>@bar.com",
	When:  time.Time{},
},
// ... obtained string = "Foo Bar <foo"
// ... expected string = "Foo Bar"
`Foo Bar <foo<@bar.com>`: {
	Name:  "Foo Bar",
	Email: "foo<@bar.com",
	When:  time.Time{},
},
// ... obtained string = "Foo Bar <foo"
// ... expected string = "Foo Bar"

[smola]

We've checked the behavior of git and it's as follows:

• When generating commits, < and > symbols are removed (no matter their position). Both for name and email.
• When reading, different operations have slightly different behaviours For example, git log prints almost the original output (no normalization), but git log --pretty='%an|%ae', which actually fully parses the signature has the following behaviour:
  • foo <my<@email.com> is parsed as name foo and email my<@email.com.
  • foo <my>@email.com> is parsed as name foo and email my.

Here's the original source in git: https://github.com/git/git/blob/3ef7618e616e023cf04180e30d77c9fa5310f964/ident.c#L250
we might want to replicate the same or similar logic for name splitting.