Define main SSVC versioning strategy in an ADR

[ahouseholder]

We will create a breadcrumb issue for us to revisit versioning policy later.

Originally posted by @ahouseholder in #500 (comment)

Summarizing discussion around #500:

• Now that we have versioning rules in place for Decision Points and Decision Point Groups, there's less emphasis on versioning for SSVC as a whole.
• However, we have a need to be able to distinguish between "versions" of SSVC for communication and marketing purposes.
• We're generally in consensus that while SemVer makes sense for Decision Points, Decision Point Groups, and other implementation-oriented details, for "big picture" SSVC versioning, a CalVer variant is likely preferable.
• We seem to be settling into a cadence of 1-2 signifiant updates a year.
• Open question on whether we prefer straight year-month numbering or year-sequence numbering (zero-indexed) i.e., 2024.3 and 2024.9 vs 2024.1 and 2024.2
• Open question how to handle "minor/patch" versioning if needed
• All conversation so far assumed 4-digit year, but that wasn't explicitly discussed. 2-digit year could still be an option (24.3, 24.9 etc.)

[ahouseholder]

Some examples of other projects using CalVer:

• PyCharm does year.minor.micro (2023.3.4 is the current version of 2023.3 for example)
• Ubuntu does short-year.month (4.10 = October 2004)