test: Migrate tests from Enzyme to RTL

[codemod]

This PR transitions all component tests in swagger-ui from Enzyme to React Testing Library (RTL), modernizing the testing approach. RTL promotes user-focused testing by simulating real interactions, making tests more robust and accessible. It also ensures compatibility with React’s evolving ecosystem, addressing limitations of Enzyme.

Description

The migration is organized for structured review:

• First Commit: Adds RTL dependencies (@testing-library/react, @testing-library/jest-dom).
• Intermediate Commits: Updates individual test files to use RTL’s render, screen, and userEvent, replacing Enzyme’s shallow, mount, and simulate.
• Final Commit: Removes Enzyme dependencies, configuration, and utilities.

Motivation and Context

• Community Support: RTL is widely adopted and actively maintained, ensuring better support and updates compared to Enzyme.
• User-focused testing: RTL encourages testing components based on how users interact with them, resulting in more meaningful and robust tests.
• Future-Proofing: With React's evolving ecosystem, RTL remains compatible with the latest features, while Enzyme has lagged in updates.

How Has This Been Tested?

All tests pass with maintained or improved coverage. The new tests are more reliable, accessible, and aligned with current React standards. Reviewers can follow the commit-by-commit breakdown for clarity. This migration future-proofs our testing framework and enhances maintainability.

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.