doc(sample.webpackGettingStarted): fix sample

[dancer1325]

Description

• Fix webpack and package configuration

---

Motivation and Context

• Why is this change required? What problem does it solve?
  • Although you follow https://github.com/swagger-api/swagger-ui/tree/master/docs/samples/webpack-getting-started, it does ❌ NOT ❌ work
    • my set up: NodeJs v20.11.0, NPM 10.4.0
    • npm install & npm start-> you get

[webpack-cli] Error: For the selected environment is no default script chunk format available:
JSONP Array push can be chosen when 'document' or 'importScripts' is available.
CommonJs exports can be chosen when 'require' or node builtins are available.
Make sure that your 'browserslist' includes only platforms that support these features or select an appropriate 'target' to allow selecting a chunk format by default. Alternatively specify the 'output.chunkFormat' directly.

---

How Has This Been Tested?

• my set up: NodeJs v20.11.0, NPM 10.4.0

• Checkout my branch, follow https://github.com/swagger-api/swagger-ui/tree/master/docs/samples/webpack-getting-started

  • rename "_sample_package.json" -> "package.json
    
  • run npm install & npm start

• Open up automatically in your desired browser the webpack devServer -- "http://localhost:8080", and check that it works and displayed the OpenAPI sample in the UI
  

• isolated changes -> just affected this sample project

---

Screenshots (if appropriate):

• Already attached per step

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.

[dancer1325]

@cat:documentation

[dancer1325]

maybe @char0n ?