Demonstrate a simple Webpack setup

[shaunluttin]

Description

• Replaces my previous PR: Demonstrate a simple Webpack setup #5183
• Introduce a docs/sample/webpack-getting-started directory.
• Demonstrate setting up Swagger UI with Webpack.
• Load the Swagger UI styles (CSS) and OAuth redirect handler.
• Authenticate against the live Identity Server demo.
• Make an authorized API call against the live Identity Server demo.

Motivation and Context

Several GitHub users have asked for or voted for improved documentation on setting up the Swagger UI with Webpack. The PR solves that problem with a working demo to which the existing documentation can link.

Here is the related issue: #4338

Here is the existing documentation: https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/installation.md#npm-registry

How Has This Been Tested?

I have run the demo locally using npm install and npm start. My local tests include authenticating against Identity Server demo and making an authorized HTTP request to the Identity Server demo API.

Screenshots (if appropriate):

The Swagger UI

An Authenticated request to the Identity Server demo API.

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.

[tim-lai]

@shaunluttin Merged! Thanks for the contribution and patience for this long open PR!