Semantic versioning of the ATC Rules

[JKrag]

I think it would make sense to at least start a conversation about potential sematic versioning of these rules.
The main purpose would be to convey information to users of the rules about the "severity" of running an update.

This is not to say that it is an urgent priority at all. I just had the thought today and a few minutes to type this out, so I figured it was better to document it here and open the discussion, or at least save it for later :-)

From a high level perspective, I see the following levels of changes/impact, and we should maybe discuss if a) I missed something important, and b) how it makes most sense to map these to a versioning scheme (preferably SemVer).

1. Minor functional changes that don't impact number of rule sets or severity of any rules at all.
2. Rule changes that only make the rules more lenient, i.e. disable previously existing rules. I.e. changes that should not catch anything on existing code that builds 🟢, but would potentially mean that you might have to/want to remove no longer needed exclusions in your custom section(s).
3. Rule changes that increase severity on one or more rules, e.g. a change where I as a project maintainer must expect to either do some cleanup work now or add new custom overrides until we have the time to fix.
4. Dependency updates to existing rule sets. These might potentially have either less or more "impact" than changing the default ATC rule settings. An update could be adding a bunch of new rules, or it just be a bugfix to an existing rule.
5. Adding a whole new rule set. I.e. expect a lot of work or at least a lot of new custom excludes.
6. Breaking changes that change e.g. the directory layout or other things (like the recent case-changing of props files. Breaking changes like this more or less require the "user" to read some sort of migration guide (or have access to internal knowledge).