Relax/make configurable the requirement for all prs to pass status checks

[chrisbarber86]

In our workflow we have:

• Create a PR with documentation for a change - this can only be approved by Team 1. This PR naturally should fail the build as the API specification has changed, but the implementation has not.
• Team 2 then create a PR that contains the implementation - this can be approved by Team 1 OR Team 2. This PR should then ensure the build passes.

Then these would be merged as a collective stack. The problem is according to https://github.github.com/gh-stack/faq/#do-all-previous-prs-need-to-be-passing-checks-before-i-can-merge that isn't going to work because all PR's need to pass the status check, which somewhat defeats the point of having a layered stack of changes. - Our status checks compare API documentation with the actual swagger output of a service to ensure that it matches up as expected. That means docs on their own would fail and equally so would implementation on it's own - only the combination of the two would pass.

Ideally what we wanted from this was the ability to avoid Team 2 having to get a review from Team 1 again when they add the implementation - as today they are having to include the doc changes in a new single PR to achieve it, which means Team 1 having to re-review it to make sure it did not deviate from the original designs in the original PR.

Really the build only needs to pass at the layer being merged up to - i.e. the cumulative result of all the PR's in the stack up to and including that point result in a passing build - so those should be merged as one big atomic stack merge. If that could be configurable as part of the ruleset config specifically around the status checks that would be ideal - since we do still want the things like reviews, codeowner reviews, requires a pull request etc all to be checked.