Specify custom OAS fields consistently

The OpenAPI spec files specify custom fields in slightly different ways. Custom Widdershins code handles both versions for documentation rendering, but the format should be consistent in the source files for clarity.

Examples cds_register.json:

"UpdatedSince": {
  "name": "updated-since",
  "in": "query",
  "description": "query filter returns results updated since the specified date-time",
  "schema": {
    "type": "string",
    "x-cds-type": "DateTimeString" // x-cds-type inside schema property
  }
},
"Page": {
  "name": "page",
  "in": "query",
  "description": "the page number to return",
  "schema": {
    "type": "integer",
    "default": 1
  },
  "x-cds-type": "PositiveInteger" // x-cds-type outside schema property
},

cds_common.json:

{
  "name": "x-cds-client-headers",
  "in": "header",
  "description": "The customer's original standard http headers [Base64](#common-field-types) encoded, including the original User Agent header, if the customer is currently logged in to the Data Recipient Software Product. Mandatory for customer present calls.  Not required for unattended or unauthenticated calls.",
  "schema": {
    "type": "string",
    "x-conditional": true, // x-conditional inside schema property
    "x-cds-type": "Base64" // x-cds-type inside schema property
  },
  "x-conditional": true, // x-conditional outside schema property as well
  "x-cds-type": "Base64" // x-cds-type outside schema property as well
}

Preference may be to only specify outside the schema property and remove any duplicate properties inside the schema object.

Specifying "x-cds-type": "enum" should not be required as Widdershins code automatically detects an enum array definition. With similar detection, "type": "boolean" fields could follow a similar approach, avoiding the need for "x-cds-type": "Boolean" to be specified.

ConsumerDataStandardsAustralia / standards-staging

Specify custom OAS fields consistently #432