GeezerVison

`Repo.blame` runs `git blame -p` and iterated over its stdout with
`bytes.splitlines()`, which breaks at a lone carriage return as well as
at a line feed. git ends every porcelain line with a line feed only, and
the content lines in that output are the raw lines of the blamed file,
so a CR inside a line of file content ended the line early in GitPython
and the rest of it was parsed as porcelain headers.

A file line such as

    ok\r<40 hex digits> 2 2 1\rauthor Forged Author\rauthor-mail <[email protected]>\r...\r\tforged()

made `Repo.blame` return an extra entry that attributes `forged()` to a
commit id and author of the file author's choosing, while `git blame`
attributes the whole line to the commit that really added it. Short of a
forgery, any line with a lone CR was truncated at the CR and the rest of
it dropped. Blamed file content is controlled by whoever wrote it, so a
tool that uses `Repo.blame` to decide who wrote a line (code ownership,
review routing, audit) could be shown attribution chosen by that author.

Iterate over a `BytesIO` of the output instead, which splits at line
feeds only and keeps the terminators, so CRLF lines and the binary-line
handling are unchanged. `blame_incremental` does not print file content
and is unaffected.

Adds `test_blame_content_with_carriage_returns` to `test/test_repo.py`;
it fails before this change and passes after. `test_blame_accepts_rev_opts`
mocks `Git._call_process`, so it now returns `b""` instead of a
`MagicMock` to the parser. `ruff check`, `ruff format --check` and `mypy`
pass. In a full clone prepared with `init-tests-after-clone.sh`, the
pytest suite passes except `test_diff_with_staged_file`, `test_empty_repo`
and `test_rebasing`, which fail the same way without this change.