Fix [behind-upstream] when dealing with subtrees

[Urgau]

This PR fixes our logic flawed logic for the [behind-upstream] handler, which just looked at the parent commit of the first commit of the branch, which doesn't work in the presence of subtree.

Instead we are using git merge-base, provided by GitHub compare API (example from the issue). This is more robust at it gives us the first common ancestors between the master branch and the pull branch.

(a side bonus is that [behind-upstream] handler is now much less complex)

Fixes #2003

[xizheyin]

Quite a beautiful solution

[xizheyin]

Is it necessary to list the link of base commit to give more adequate hints?

[Urgau]

We could give similar instructions as when we detect merge commits.

triagebot/src/handlers/check_commits/no_merges.rs

Lines 70 to 75 in 14fefb6

	You can start a rebase with the following commands:
	```shell-session
	$ # rebase
	$ git pull --rebase https://github.com/{repository_name}.git {default_branch}
	$ git push --force-with-lease
	```"

[Kobzol]

We could make upstream commit be a link to the merge base, to show people the old master commit.

[xizheyin]

Yeah, it will be more convenient for the author to check the mistakes. :)

[Kobzol]

Shame that GitHub doesn't include this directly in the main PR message. I did a few experiments and tried to think of simpler heuristics, but the merge base seems like it should be robust against various edge cases and issues. Left one nit, but with or without dealing with it feel free to merge.

[Kobzol]

We could make upstream commit be a link to the merge base, to show people the old master commit.

[Urgau]

I may not be avalaible this week-end, I will merge it now, as to fix the false positives, and fix the nits in a follow-up PR.

[xizheyin]

I would like to fix the nit if you are not free. I just finished my vocation.

[Urgau]

Sure, go ahead.