[ci] Don't use latest `main` for PRs

[driazati]

Here we find the latest commit and merge with it before running a PR through CI to prevent merge conflicted PRs from taking up CI time.

tvm/ci/jenkins/Prepare.groovy.j2

Lines 17 to 26 in caf326f

	sh (
	script: 'git fetch origin main',
	label: 'Fetch upstream',
	)
	if (upstream_revision == null) {
	upstream_revision = sh(
	script: 'git log -1 FETCH_HEAD --format=\'%H\'',
	label: 'Determine upstream revision',
	returnStdout: true,
	).trim()

This is fine except when we change the Jenkinsfile that always comes from the PR's git merge-base origin/main <pr_commit>, so if that references files that have been moved in the latest commit on main there will be random CI failures like https://ci.tlcpack.ai/blue/organizations/jenkins/tvm/detail/PR-12648/3/pipeline/. To fix this we should either:

1. don't merge at all and run the PR as is
2. find the last 'safe' commit (i.e. the last commit between origin/main and the git merge-base origin/main <pr_commit> that has no Jenkinsfile modifications) and merge to that

cc @Mousius @areusch @gigiblender

[areusch]

is this solved by #12604 ? i guess not, since it needs to know where they were moved to is the issue?

[driazati]

right (this was actually caused by #12604), this issue would happen for any file referenced from the Jenkinsfile

[areusch]

one thing is--is this just a one-time transient issue while we reorg the code tho?

[driazati]

Yes, it can be fixed by the user by rebasing and thus changing the git merge-base origin/main to one that matches the file structure on origin/main, so this isn't like a huge deal just a minor disruption that we could avoid