Add support for expandable OpenAPI.webhooks grouped by tags

[PratikMane0112]

Add support for expandable OpenAPI.webhooks grouped by tags

Description

This PR implements support for expandable OpenAPI.webhooks grouped by tags in Swagger UI, similar to how OpenAPI.paths are currently handled. The implementation provides:

• New selectors (webhooksWithTags and taggedWebhooks) to properly group webhooks by their tags
• Updated Webhooks component to use these selectors for proper rendering
• Expandable/collapsible sections for each tag group
• Support for webhooks with multiple tags (appearing in each relevant section)
• Default tag section for untagged webhooks

Motivation and Context

Fixes #8490

This change improves the user experience for OpenAPI 3.1.0 specifications that include webhooks by organizing them into collapsible tag groups, consistent with how paths are displayed. Previously, webhooks were displayed as a flat list without tag organization.

How Has This Been Tested?

I've verified my changes in a local environment using webpack dev server with a test OpenAPI 3.1.0 document containing tagged webhooks.

Screenshots (if appropriate):

Webhook Tags Overview :

Expanded Webhook Sections :

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.