Handle and persist checkrun webhook events.

[ajshepley]

Ref: #1167

When we receive a status webhook event, we use the webhook data to persist the statuses. This helps with timeliness.

However for checkruns, we wait for a CheckSuite event, which does not contain checkrun information, and we enqueue a refresh which will then retrieve checkrun information.

It turns out that we are also receiving CheckRun webhooks, which do provide enough data to create a checkrun record.

So this PR adds a handler for those events, and attempts to persist them using the existing logic.

Paired with the target PR #1167, this should make Shipit-engine more robust against stale and incorrect data from GitHub's end, by ensuring that we commit. It should also make it a bit faster in responding to checkrun changes, though in practice, the refresh job is quite fast already (fast enough to cause the issues mentioned in #1167).

Alternative Option

Instead of persisting the checkrun, we could also enqueue a refresh job just as CheckSuiteEvent does. But since the target PR adds guards for webhook ordering and staleness, I see no large drawbacks in just persisting the data we've received in this webhook.

In theory, every checkrun event would have checksuite events nearby, but in practice this does not appear to be the case, so persisting the "more correct" data we seem to receive from webhooks, and deferring to it based on timestamps, seems like a good improvement to make.

[JackTLi]

Just dropping by for fun, this looks cool!

[ajshepley]

Thanks Jack!

---

Very strangely, the head commit of this PR has a failing status, but the PR itself is somehow green.

It seems like re-running the GitHub Actions check only applies the statuses to the PR, rather than to the head commit of the PR.

Interesting quirk...