Don’t cancel try builds when the PR is pushed

[SimonSapin]

Steps to reproduce:

• I work on https://github.com/servo/servo/pull/12943, make a few commits. There is more to do before reviewing/merging, but at that point I want to make sure my refactoring actually works.
• Open the PR and start a try build
• Since it’s gonna take a while, I keep working and make some more commits and push them

Actual result:

• Homu sees that the branch has changed, and decides it’s not interested in that try build anymore even though the builders have been running for almost an hour. (I’m not sure the jobs are even canceled to make progress in the queue, the results might just be dropped at the end.)
• The PR is then reviewed and r+’ed
• It turns out my initial refactor did have one bit missing, and a test fails.
• I need to do an other round of babysitting CI bots.

Expected results:

• Homu comments on the PR with the result of the try build even if the PR’s HEAD has changed. I’m still interested in those results, that’s why I started the try build!

CC @larsbergstrom

[Manishearth]

Jobs aren't ever canceled except with force.

But yes, it does ignore the results.

It should really also report all results of a try build (report the first failure when it happens, and report all failures when the entire set of builds completes)

[Manishearth]

To do this we'll need to add a new old_merge_sha field into the state object (which is also saved in the pull table). This field mirrors merge_sha, but is not overwritten on head_advanced().

(We rely on the merge sha being the merge sha of the updated PR in a few places, so it's best to avoid this entirely and save a second merge sha for try builds)

Alternatively, without changing the db schema, we could just append old- to merge shas when the head advances, and check for this in get_state.