README.md file in annex can break web UI if the annex'ed file is not pushed to gin

**Describe the bug**

The web UI of a repository emits the error `template: repo/view_list:9:72: executing "repo/view_list" at <.LatestCommit.Author.Email>: invalid value; expected string` if the README file of that repository is part of the git annex but is not pushed to gin. (See: https://gin.g-node.org/matrss/test_readme_in_annex2)

**Gogs version and commit**

This happens on the live version at https://gin.g-node.org as well as the live tag of the official docker container.

**To Reproduce**
I've used datalad, but this should be reproducible with plain git/git-annex as well. For datalad:
1. Create a datalad dataset: `datalad create ; cd `
2. Add a README file: `echo "# Test" > README.md`
3. Save the dataset: `datalad save`
4. Create an empty repository at gin.g-node.org
5. Add it to our dataset: `datalad siblings add -s gin --url `
6. Push: `datalad push --to gin`

This version works fine. If we now clone this dataset and do the same again:
1. `datalad clone ; cd `
2. Create another empty repository at gin.g-node.org
3. Add it to our dataset: `datalad siblings add -s gin --url `
4. Push: `datalad push --to gin`

The resulting repository should exhibit the same error as https://gin.g-node.org/matrss/test_readme_in_annex2. This is presumably because the pushed clone did not have the annex'ed content of the README file and therefor it was also not pushed to gin. Gin seems to unconditionally try to load it though.

**Expected behavior**
Some more informative error message, possibly not breaking the whole rendered page and instead just showing some error where the README would be shown.

**Actual behavior**
The above mentioned error message which does not seem to have anything to do with the actual error.

**Additional context**

We found multiple messages of the form:
```
2021/11/09 09:43:46 [ERROR] [...ute/repo/repo_gin.go:125 resolveAnnexedContent()] Failed to find content location for key "MD5E-s108--cfc5fc2e6543b98b7f04a942c2133a12.md"
```
in the logs of our own instance.