Suppressions as a checked in resource do not make sense

[tjprescott]

Suppressions were introduced here (#47). The goal behind having a yaml file is that you could add point suppressions with a rationale, and these point suppressions would be approved as part of the PR by the relevant approvers.

This model has some fundamental flaws, because once the PR is approved, that suppression file will be checked in as an artifact.

Fundamentally, the suppressions only matter between two specific versions of the API. If you suppress something going from version 1 to 2, when you go to version 3, if that item is unchanged from version 2 you have no diff and the suppression does nothing. However, if you DO change something between version 2 and 3, you very likely want to re-review it, but the suppression will suppress the change and allow it in!

So fundamentally, we would need to rethink how this feature works.