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.
* Configure syntax highlighter to use CSS classes
the inline `style` attributes cause CSP errors (and don't work). Instead, we
can use proper CSS classes.
* Configure response headers for Hugo dev server
make the dev server serve response headers which match the live site, for
better testing.
Now that we've dropped the old build pipeline (and an assets directory does not exist in the repo any longer, we can rename the hugo version of the assets (assets-hugo) created during the build tools migration back to simply assets.
