Bug: Autostatus does not work when pipeline is triggered by PR comment

# Bug

Triggering builds with PR comments is provided by the [pipeline-github-plugin](https://github.com/jenkinsci/pipeline-github-plugin).

When a build is triggered by the cause `org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause` then the GitHub autostatus plugin logs

```
INFO: Could not find commit sha - status will not be provided for this build
```

And does not vote status contexts to GitHub.

# Additional information

However, after the build is completed (finished entirely) I can run the script console command to get the revision in a similar manner as this plugin.

More details (Click to expand)

---

Some investigation using the Jenkins script console.

```groovy
import jenkins.model.Jenkins
import jenkins.scm.api.SCMRevisionAction
import org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision
import org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause

def build = Jenkins.instance.getItemByFullName('someproject/PR-1455').getBuild('2')

// the following returns org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause@14ba189
println build.getCause(IssueCommentCause)

// the following returns boolean true
println (build.getAction(SCMRevisionAction).getRevision() instanceof PullRequestSCMRevision)

// the following returns a proper SHA1 Git hash
println build.getAction(SCMRevisionAction).getRevision().getPullHash()

// the following returns class org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision
println build.getAction(SCMRevisionAction).getRevision().getClass()
```

Which the println statements return (in order)

* returns `org.jenkinsci.plugins.pipeline.github.trigger.IssueCommentCause@14ba189`
* returns boolean `true`
* returns a proper SHA1 Git hash
* returns `class org.jenkinsci.plugins.github_branch_source.PullRequestSCMRevision`

---

# Possible solution

It appears that `build.getAction(SCMRevisionAction)` is `null` when a build is first initiated but the first time an `scm checkout` occurs the run is populated with an `SCMRevisionAction`. This seems to be a unique situation when `IssueCommentCause` is the cause for triggering a build (so no SCM information is available, yet).

Does it make sense to add protective code where if [`GithubNotificationConfig.java`](https://github.com/jenkinsci/github-autostatus-plugin/blob/master/src/main/java/org/jenkinsci/plugins/githubautostatus/GithubNotificationConfig.java) gets a null result then to put in a "dummy" config which tries to update itself as revision information becomes available?

# Reproduce Error

### Setup environment

* Configure Jenkins to use webhooks with GitHub.
* Install `pipeline-github` plugin.
* Add a multibranch pipeline job for a project.
* Within a Jenkinsfile for a pull request have the following code:

```Groovy
// this will fail if merged into master but works from a pull request
properties([
pipelineTriggers([
issueCommentTrigger('.*test this please.*')
])
])
stage('hello') {
echo 'hello'
}
stage('world') {
echo 'world'
}
```

### Reproduce issue

1. Let the PR pull request run at least once so that PR comment triggers get configured for the job.
2. Comment in the pull request `retest this please`.
3. After a "comment" build runs
* it will update the GitHub status context `continuous-integration/jenkins/pr-merge` or `continuous-integration/jenkins/pr-head` depending on what you have configured in the multibranch job.
* it **will not** update the status for stages. Notice the `pr-merge` (or `pr-head`) context will have the latest build but the stages will have the older build.

# More info

I'm on github-autostatus plugin 3.2 so the relevant code from my Jenkins logging is https://github.com/jenkinsci/github-autostatus-plugin/blob/github-autostatus-3.2/src/main/java/org/jenkinsci/plugins/githubautostatus/GithubNotificationConfig.java#L148-L165

I looked at #29 which is the only update to that code in newer releases. I don't think upgrading will resolve my issue.

Start with GithubNotificationConfig.java around lines 148-165 and inspect how the build cause and SCMRevisionAction are handled at initiation and after checkout. Reproduce with the provided pipeline-github issueCommentTrigger example and compare stage status contexts before and after checkout. Done means comment-triggered builds update stage statuses in GitHub consistently with other builds.

Written by the indexing model from the issue text.