When looking at the "Authentication Data" type used in e.g. the account
deactivation endpoint
https://spec.matrix.org/v1.3/client-server-api/#post_matrixclientv3accountdeactivate
it was not clear to me that clients and servers should expect additional
fields in this structure (the semantics of which are implied by the
`type` of the authentication, or that of the previously established
`session`.)
In the OpenAPI spec, We occasionally mark some ojects as allowing
arbitrary additional properties (`additionalProperties: true`, or
`additionalProperties: { description: "..."}`). In other places we are
more strict and provide a schema that additional properties must satisfy.
In this PR we aim to make the first kind of additional
properties (non-strict) more visible in the rendered spec.
* Fix rendering of response examples
Fixes the autogeneration of JSON examples for array objects. This fixes a
number of "Specification error: Example invalid or not present" errors in the
rendered spec.
* Unbreak examples for non-objects/arrays
The previous change had broken auto-generated examples for everything that
wasn't an object or array; fix it up again.
* Remove conditions on $example
Everything should now have a generated example, so the condition is
redundant. Furthermore it was suppressing examples for APIs where the example
was an empty dict.
* Introduce a new "added-in" template and use it on endpoints
* Use "added-in" on schema properties too
* Annotate sections of the spec with their added versions
* Demo of "added-in" on a room version (to be fleshed out)
* Use clearer versioning semantics
* Update and fix validator for Swagger custom properties
* Fix docs
