feature: JsonSchema components are now ImmutableJS compliant (#5951)

[tim-lai]

Description

Fixes #5951

• JsonSchema-based components are now ImmutableJS-compliant
• JsonSchemaForm now properly defaults to JsonSchema_string for invalid or unknown types, as well as unable to getComponent cases
• JsonSchema_array now uses a simplified JsonSchemaArrayItemText component
• JsonSchema_array handles its own subcomponent render logic, rather than recursing from its JsonSchemaForm parent
• Additional validation checks to confirm that "schema" keys, "schema" values, and ImmutableJS methods exist
  • schema
  • type
  • format
  • enum
• bug (separate pre-existing): Debounce error if string value is null
• Existing Mocha json-schema-form test now uses ImmutableJS parameters instead of plain objects
• New Cypress tests for schema-form
• Added new dev Cypress open scripts

Motivation and Context

• If an API definition contained a missing schema key or if schema key was missing expected values, the SwaggerUI client could crash or appear to be stuck in an indefinite loading state
  • Expand operation, e.g. missing schema values, ImmutableJS compliance
  • Try It Out, e.g. ImmutableJS compliance
  • Execute, e.g. debounce error, ImmutableJS compliance
• A use case would be a work-in-progress API definition using Swagger Editor, where a user might "Try It Out" before validating the work-in-progress API definition as valid
• There were two main issues:
  1. Codebase assumed that schema key(s) would always exist
  2. JsonSchema components could mutate away from ImmutableJS. This could lead to removal of schema key(s)

How Has This Been Tested?

• Existing Mocha json-schema-form test now uses ImmutableJS parameters instead of plain objects
• New Cypress tests for schema-form
  • includes a section extending Arrays from multiple-examples-core.openapi.yaml

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.