Establish a versioning and branching scheme for AQAvit project

[smlambert]

For several reasons, it is time for us to implement a versioning/branching story for AQAvit. Reasons include:

• help us clarify and define the steps for marketplace vendors to use
• aids in the reproducible test story
• allow us to continue working in tip while we release, as we can use a branch for the release (we are having so many PRs backlogged during code freeze, that this will be very helpful)
• help us better categorize the type of changes that occur

In terms of what we need, we look at some standard versioning approaches, from semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

This is relatable to our AQAvit reality. For MAJOR version updates, which are very rare, they may happen when we make a dramatic change in TKG that changes and becomes incompatible with earlier versions of test definition files (playlists) and/or test material. For MINOR version updates, this includes the addition/removal of test targets or test material. For PATCH version updates, it may include test material tag changes or single test case exclusions in Problem list files.

[smlambert]

Tag naming scheme is vMAJOR.MINOR.PATCH
and release branch naming scheme is vMAJOR.MINOR.PATCH-release.

Release branches will have their testenv.properties file updated to the appropriate key/value pairs for the main repositories that are pulled in and used as part of the AQAvit project (including TKG, aqa-systemtest, STF, bumblebench, openjdkXu, openj9). For use by AQAvit certification purposes, the QVSL license will also be added to the release branches.

[smlambert]

Closing as we now tag and release following this scheme.