Automating mappings search

Consider the best-case scenario of dealing with dangling references, as described in README:

> The best-case scenario for you is that you find a repo that still has these commits. You can then look at their metadata (commit message, date etc.) and find the corresponding commits in the submodule's new history.

This could be automated:

1. user redirects git-submerge's error to a file. It doesn't even need to be a special format—we can just read anything that looks like a SHA-1, and ignore the rest;

2. user runs some other tool (let's call it `helper`) in a repository that might still have some of those old commits. The tool looks up the SHA-1, and if it finds the object, it should look through the rest of the objects to find any that have the same metadata (date, author, commit message etc.) We'll presume that dangling references are because of cherry-picking.

3. The tool outputs a mappings file in the format acceptable to `--mappings-file` (yet to be implemented).

Technically this breaks my ideology of "commit is a statement", because if commit ID changed after cherry-picking, then the state of this commit is different from original (even if the metadata is the same). So if we just use it in place of another, we might be breaking a statement someone made about the repo (because they included another commit, not this one).

But other users of git-submerge might not care about my ideology.