Add resolveSubtreeOnExpand option to skip subtree resolution on expand

[paulwellnerbou]

Description

Adds a new resolveSubtreeOnExpand configuration option (default true, preserving current behavior). When set to false, Swagger UI no longer resolves an operation's or model's subtree when it is expanded, and renders directly from the unresolved spec instead.

Resolving a subtree dereferences every $ref, merges compositions, and generates samples. For documents with many deeply nested oneOf compositions, doing this work on expand can freeze and eventually crash the browser tab (#10917). Setting resolveSubtreeOnExpand: false skips it, keeping expansion responsive — at the cost of rendering the unresolved schema ($refs are shown by name). To keep that view readable, models now derive their display name from $ref/composition when no explicit name is present.

Motivation and Context

Fixes #10917. Some valid OpenAPI documents — particularly those built from many nested oneOf schemas — freeze and crash the browser tab when an affected operation is expanded, because expansion triggers full subtree resolution and sample generation. This option lets such documents opt out of resolution-on-expand and stay responsive.

The default is unchanged (true), so this is a non-breaking, opt-in change.

How Has This Been Tested?

• New Cypress e2e test verifying a schema model renders its properties when expanded with resolveSubtreeOnExpand=false.
• New/updated unit tests for the config type-cast and the json-schema-5 model components.
• Existing unit and e2e suites pass.
• Manually verified against an anonymized real-world schema with deeply nested oneOf compositions, deployed for side-by-side comparison:
  • Before (default, resolution on): https://wbou.dev/swagger-ui/master/
  • After (resolveSubtreeOnExpand: false): https://wbou.dev/swagger-ui/performance-improvements/
  • Reproduction schema: https://wbou.dev/swagger-ui/latest-schema.anonymized.json — expand GET /v1/resource007. The "before" deployment freezes/crashes; the "after" one stays responsive.

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 (docs/usage/configuration.md).

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.