CASMCMS-8959: Correct errors in API spec

[mharding-hpe]

This corrects several errors I found when reviewing the CFS API spec recently:

• Several description fields have minor errors (usually seemed to be copy-paste errors when the schema was created based on another schema). A couple of example fields had the same issue.
• The Version schema claims that the major, minor, and patch fields are integers, but in truth CFS has always returned them as string values. Looking at the source code, I can see why. Given that CFS has always behaved this way, it seems better to update the API spec to reflect reality, rather than change the API behavior.
• The version endpoints claim (in summary and description texts) that they return lists of versions, but in truth they just return the current version.
• For paginated responses, the next field is null when there are not additional pages. The API spec does not convey that this field may take a null value.
• The V3SessionIdCollection schema says it is a list of sessions, but as the name implies, it actually is a list of session IDs. The actual CFS behavior reflects this.
• Several paginated response schemas had copy-paste errors for the data array property (all of them say the property is named components, even though it actually varies based on the endpoint being paginated).
• In several cases, the spec used $ref and specified options as siblings of it. However, in OAS 3.0.x, any siblings of a $ref are ignored. For example, if you say that a given property follows some schema (by using a $ref) but then also list that this property is readOnly or nullable, those latter options are ignored. In OAS 3.0.x, there are two ways this is generally handled.
  1. Use allOf, listing the referenced schema, and then an empty schema which has the other desired values. This option in some ways is the cleanest choice, but unfortunately a number of people have reported that a lot of tools do not handle parsing it very well. Because of that, I opted to do:
  2. Make a new schema that is a copy of the one being referenced, but with the additional settings added to it. Then reference the new schema (or just embed it).

Most of them are updates to schemas which the actual CFS code never uses, and thus will have no functional impacts. Only two of the changes impact schemas which are used by the code (V2ComponentState and Version). I reviewed the code that uses these models to make sure that the changes should not impact them. I also deployed this on mug and ran both manual CFS tests and the cmsdev CFS regression tests, and verified that it worked.

Backports:
CSM 1.5: #113
CSM 1.4: #114