Display the OAuth2 Redirect URL in the authorization dialogue along side the existing URLs

[andrewnicols]

Description

The OAuth2 Redirect URL defaults to a value, but can be overridden by the oauth2RedirectUrl config parameter; however neither the default value nor the custom value are ever surfaced in the UI. The only way to find the currently used value is to attempt to authenticate, and grab the value from the URL.

This change adds the current value of the OAuth2 Redirect URL to the Authorisation dialogue, just underneath the Authorization URL and Token URL values.

Motivation and Context

This change adds information which is otherwise difficult to find and makes it easier for users using a hosted Swagger UI where they are still responsible for configuring the client properly.

How Has This Been Tested?

Unit tests included.
Also tested manually with the local dev environment and checking that:

• the value is not shown for the standard petstore schema with and without a custom oauth2RedirectUrl set
• the default value is used if none is specified and an oauth2-capable schema is specified
• a custom value is used if one is specified

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.
• [ x 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.