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.

No file or test is named in the issue; start by reviewing the proposed major, minor, and patch categories and the issue comments. Done means the configs working group has resolved the judgment calls and documented guidelines for incrementing the three-part config version string.

Written by the indexing model from the issue text.