Inconsistency in when "Required for merge" checks are considered satisfied.

Describe the bug

If a repository is set up with merge checks to require that a certain job succeeded, then the definition of succeeded is inconsistent across the product.

1. If you use the if: <bool> key in a job, then the job is considered to succeed if the boolean value is false even though the job did actually not run. That is a reasonable definition, basically "succeeded means it did not fail". This is a very useful definition to be able to scale the workflow while keeping runtime down. I propose to not change this.

2. On the other hand, if you use the path key feature for the entire workflow then the job is considered to not have succeeded if the job did not run (because the workflow did not run).

So here there are two instances of "job did not run" that lead to a different decision by the merge checks logic. I propose to change the workflow/path logic to count skipped jobs as succeeded the same way as you already do with if.

Our use case is that we try to use Github Actions for a mono repo with lots of workflows while keeping the triggered jobs down to what is actually needed to be done based on the changeset. For us, the ideal behavior would be that required jobs from workflows that did not run because of no changes were also considered as satisfied.

Start by tracing the merge-check handling for workflow-level path skips and job-level if skips described in the issue. Compare how each case is marked when a job does not run; done means skipped jobs from workflows excluded by paths satisfy required checks consistently with skipped jobs controlled by if.