GeezerVison

`Commit._serialize` wrote `Actor.name` and `Actor.email` into the `author`
and `committer` headers exactly as given. Each identity is a single line of
the form `name <email> date`, so a line feed or an angle bracket inside
either field moves those boundaries.

A line feed in the author name ends the `author` line and the remainder is
read as further headers. `author` is written before `committer`, so a
`committer` line supplied this way is the one Git and
`Commit._deserialize` use, and an empty line ends the headers so the rest
becomes the message. With the committer pinned by a service and only the
display name taken from its user, the name

    Eve <[email protected]> 1700000000 +0000
    committer Release Manager <[email protected]> 1700000000 +0000

    Approved-by: Release Manager

produced a commit that `git log` attributes to committer
`Release Manager <[email protected]>` with the subject
`Approved-by: Release Manager`, and `git fsck` reported nothing for it.
Without a line feed, `<` in a name or `>` in an email still presents
another email: the name `Release Manager <[email protected]> x` with the
email `[email protected]` reads back as `[email protected]` in both Git
and GitPython.

Git removes these three characters when it formats an identity
(`strbuf_addstr_without_crud()` in `ident.c`), so `git commit-tree` given
the same `GIT_AUTHOR_NAME` cannot write such a commit. Check the name and
email of both identities at the start of `_serialize` and raise
`ValueError` if one contains `<`, `>` or a line feed. `create_from_tree`,
`IndexFile.commit` and `replace` all store the commit through this method,
and the check runs before the object is stored and before `HEAD` or its
reflog are updated. It raises instead of removing the characters, like the
tree and index serializers that reject invalid entries, so a caller is not
left with an identity it did not ask for. The `back-to-the-roots` branch
(gitpython-developers#2262) already refuses these characters before calling `git commit-tree`;
this covers the native serializer until then.

Identities without these characters are written as before. `_deserialize`
can return such a field only from a commit that `git fsck` already reports
as `badName` or `badEmail`, for example `A> B <a@b>` or `A <<a@b>>`.
Serializing a commit like that again, for example through `replace()`, now
raises too. None of the 5466 commits in this repository is affected and
`test_serialization` still reproduces every object ID it checks. NUL and
carriage return are left alone: neither moves a field boundary, and Git
keeps a carriage return inside a name.

`test_identity_cannot_alter_headers` covers both fields of both identities
through `create_from_tree` and `replace`. It fails on the previous code and
passes here. The full suite has no new failures on macOS with Python 3.11
(the six `nul\x00name` cases of
`test_submodule_rejects_unsafe_checkout_before_mutation` fail there with
and without this change), and `ruff`, `mypy`, `basedpyright --warnings` and
the documentation build are clean.