Consider CI statuses which don't rely on source code to be blocking

[joao-paulo-parity]

Problem: processbot disregards all failing CI statuses from companion PRs before merge because it assumes that the companion is failing due to incorrect dependency references (explained in #250 (comment) and #327). The issue is that not all checks are reliant on code, which means they aren't affected by the outdated dependency references, so it doesn't make sense to ignore them on that basis.

An undesired side-effect of this "ignore everything" approach was mentioned in https://github.com/paritytech/ci_cd/issues/159#issue-939082694.

so many times, we do bot merge on substrate, it works, and then when merging polkadot, it fails because it doesnt have some stupid labels

Tying that to the initial explanation: the label checks are used to ensure that PRs have the right labels, mostly for the sake of release notes, i.e. they aren't reliant on code, thus they shouldn't be ignored.

Solution: We should stop ignoring CI statuses which don't rely on source code, primarily because those checks might get in the way of merging the companions, as mentioned in https://github.com/paritytech/ci_cd/issues/159#issue-939082694.

Since our code-reliant checks generally run on GitLab, one idea would be to consider that all failing checks which aren't coming from GitLab are blocking. To detect that a check is coming from GitLab we can either go by the check's name (GitLab checks start with continuous-integration/gitlab- as per https://gitlab.parity.io/parity/opstooling/vanity-service/-/blob/bc3babe549922cde8772acf27c458d4e7d99c426/src/app.ts#L124) or by their target_url.