[robert-hebel-sb]

Description

Render the header of a standalone JSON Schema document (JSONSchemaDocumentInfo: document name as heading, dialect and document-kind stamps, base/retrieval URIs and description) and its definitions (JSONSchemaDocumentDefinitions), wired into JSONSchemaDocument, with styles.

Part 5 of 5 of a stack on top of #11117 (standalone JSON Schema 2020-12).

Motivation and Context

Completes the document-level rendering of a standalone JSON Schema document. The stack is blocked until the swagger-client release it needs is published.

How Has This Been Tested?

• Unit tests (npm run test:unit -- test/unit/core/plugins/json-schema-document) and ESLint on the plugin and its tests passed locally before the tarballs were removed from package.json.
• Playwright specs for the header and definitions are included; they were not run.
• Not re-run against the released swagger-client (the tarballs are dropped in feat(json-schema-document): render standalone JSON Schema 2020-12 #11117); CI is expected to fail until the release this stack depends on is published.

Screenshots (if appropriate):

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.