Guidelines for incrementing the config part of the version string

The name of the configs contains a string with three versions. For example: `cg-config-v1.0.0_aces-v1.3_ocio-v2.1`. It is self-evident what the ACES and OCIO versions should contain but the guidelines for when to increment the config part have not been documented. The following guidelines are proposed as a strawman for further discussion:

Major version increment:
- Adding color spaces
- Adding displays

Minor version increment:
- Adding looks
- Adding new views to existing displays
- Adding named transforms
- Role changes
- Significant changes to existing transforms
- Changes to aliases

Patch version increment:
- Removing color spaces, displays, views, if they are kept in the inactive list
- Minor changes to existing transforms
- Changes to description text
- Changes to family, categories, encoding
- Changes to file_rules or viewing_rules
- Changes to active_displays, active_views, inactive_colorspaces
- Changes to default_view_transform

I'm on the fence about some of these. In many cases it could be a matter of degree (was it a big change or a small change) and so it's difficult to come up with absolutely fixed rules. Therefore, it seems prudent to refer to these as "guidelines" rather than "rules" to indicate that in some cases there will be a judgment call made by the configs working group on how to assign a new version string.

In der Issue wird keine Datei und kein Test genannt; beginne damit, die vorgeschlagenen Kategorien major, minor und patch sowie die Kommentare zur Issue zu prüfen. Erledigt bedeutet, dass die configs working group die Ermessensentscheidungen geklärt und Richtlinien für die Erhöhung der dreiteiligen config version string dokumentiert hat.

Vom Indexierungsmodell aus dem Issue-Text verfasst.