Add observability into "violations" for rubocop based package protections

[alexevanczuk]

For privacy and dependency enforcement, we have two primarily metrics:

1. Count of packages that have the enforcement turned on
2. Number of violations related to the enforcement

Note that for (2), We compute this regardless of whether the enforcement is on or off at Gusto (i.e. we turn on the protection then run packwerk)
Note also that for both (1) and (2), we compute these metrics by package and also by team.

For rubocop based protections, such as typed API or namespace protection (shipped with package protections) or other Gusto-specific protections, we only count the number of packages that have the protection turned on (also aggregated by team).

We do not currently capture how many violations there are, so we do not have a true vision of progress. That is – 100% of packages can have a protection turned off with 100% of the code in those packages not conforming to the protection via rubocop exclusions.

This PR DOES capture:

1. The total count of exclusions for each rubocop based protection

This PR DOES NOT capture:

1. The count of "violations" in the same vein as (2) above, as we won't be "turning on the protection" and rerunning rubocop to get the true count of violations. This means the semantics for this metric are different compared to privacy and dependency enforcement. For technical reasons, I think this may be acceptable for now, because although packwerk makes it simple by its design to turn on a protection and count violations, this may be more challenging to do. If we wanted to, we could actually delete all .rubocop_todo.yml files and run bundle exec rubocop --only=PackageProtections/CopName --format=files. However, I'm afraid that will be a bit of a maintenance nightmare, for now. For that reason, I opted to only capture exclusions as they are in the codebase. For this reason we can expect to see the metric rapidly going up and down as folks turn protections on and off. I think this is fine. We can focus on two separate goals: getting the protection turned on, and then working the exclusions list down.
2. This does not capture per team or per package based metrics. That is – we cannot look at how individual packages or teams have reduced their rubocop exclusion lists. I think this is fine and I think having the eagle eye view of progress is all we need.

[shageman]

It seems to me like concern #1 is at least as much in control of the implementing organization as counting "all" (even non-activated enforcements) for privacy and dependency. Anyone who'd like to implement the script can do so.

I agree that it is a step in the right direction to expose the total metric. Maybe someone (including us) wants to invest in team and package based metrics later on.

[shageman]

Filling a knowledge gap: Can someone opt accept a rubocop based protection violation by commenting on a line instead of the todo list entry?