SIG Content Guide should have information on acceptable dist tags, and explain overriding versions by appending Release

[NeilHanlon]

wiki.rockylinux.org/docs/special_interest_groups/sig_guide/content.md

Lines 75 to 106 in 49f1dfd

	### Branch Names
	Branch naming is **important**. **main is NOT an acceptable branch name under any cirumstances.**
	You **must** use `rX` as the prefix, `X` being the major version number. All packages that are part of a SIG and will be in a peridot project together must have matching branch names.
	To support multiple versions, there will need to be multiple projects and branches need to be named appropriately. Multiple versions of a package cannot coexist in a single peridot project.
	#### Multiple Versions + Multiple Projects
	There may be cases where:
	* Multiple version of a package will exist in some form and/or
	* Although the cases may be rare, sets of packages may not coexist with others and live in completely separate projects.
	If this applies to your SIG, you can use branch names and the proper configuration in peridot to make this separation possible. The names of the branches are used to separate packages if need be. See the ideal template:
	`rX-sig-SIGNAME-VERSION`
	* `rX-sig` is considered the SIG prefix
	* `SIGNAME` would be the name of the SIG (for example, `kernel`)
	* `VERSION` is required. This can be numerical or simply another name/acronym.
	Examples:
	```
	* Kernel SIG for kernel 5.15 (Rocky Linux 8): r8-sig-kernel-5.15
	* Kernel SIG for kernel 5.15 (Rocky Linux 9): r9-sig-kernel-5.15
	* Kernel SIG for kernel 6.1 on (Rocky Linux 8): r8-sig-kernel-6.1
	* Kernel SIG for kernel 6.1 on (Rocky Linux 9): r9-sig-kernel-6.1
	```

should have a section on Dist tags, and managing upgrade paths by appending to Release field (i.e., https://git.rockylinux.org/staging/patch/cloud-init/-/blob/r9/ROCKY/CFG/cloud-init.cfg#L11-14)

[NeilHanlon]

@nazunalika corrected me that we do have information on dist tags already. Let's take a pass at the build page and ensure it's accurate.

I'd also like to see if we can/should restrict this further in Peridot itself. We do some checking for if the project's dist tag has elN where N is the project's configured Major Version, but, it doesn't enforce that it starts with this, just that it contains it. Of course we can't make this too restrictive, but, we'll discuss that on the Peridot side.