Fix using migrate-downstream-fork with up-to-date monorepo

[DragonDisciple]

Commit 2f2aeb9b has the following in its log:

llvm-svn: 181277
llvm-svn: 181274
llvm-svn: 181273

I assume this is because it is a commit that exists in 3 subprojects, and
thus has 3 separate svn revisions which were combined during monorepo
conversion.

find_svnrev assumes a 1-to-1 git commit to svn revision correspondance
which seems inaccurate with how the monorepo is now laid out.

This commit now has the function return a list of tuples, so that we can
represent the 1-to-many git commit to svn revision relationship.

This also required a change to the regex, which used '\Z' to match the
assumed 1-to-1 svn revision associated with the commit. This assumption is
no longer true in the monorepo. The new strategy is to start at the end of
the message and work our way up, matching each line as an svn revision
until we reach the first non-match.

Fixes #18

[DragonDisciple]

This is more or less a concept that I hacked together after comprehending what the functions were doing. I didn't make any great attempt to refactor or simplify the data structures. It works for our team's repository, and has successfully migrated it to the monorepo. If you see no issues with it, we can get it merged in.

The key things that I'm curious about changing after understanding more is the change to a list for base_svn_revisions object. It seems dirty how I hacked in the changes to it, and would be amenable to updating it if I get more assumptions I can go by through understanding more about the monorepo conversion.

I had 2 assumptions I made during development:

• Old git commits have a 1-to-1 mapping to svn revisions
• Monorepo revisions never have subproject information

I tested these and they came back true across the board (DragonDisciple@39885b0)