fix(styles) restore wrapping of long text in pre blocks

[scottohara]

Description

Adds overflow-wrap: break-word to <pre> blocks in markdown.

Motivation and Context

In Swagger UI version 3.24.1 (November 2019) a CSS change was made to _layout.scss that added the .microlight class to the .opblock-body pre selector. (#5673)

Prior to this change, a <pre> block in an operation description that contained long text content with no spaces or other natural break points would automatically wrap onto new lines, because the .opblock-body pre selector (now .opblock-body pre.microlight) includes overflow-wrap: break-word.

After the above change, this CSS selector no longer applies to <pre> blocks in the description, causing long unbroken text to overflow out of the right edge of the container.

(see screenshots below for before & after).

This change adds the overflow-wrap: break-word style to the .markdown pre and .renderedMarkdown pre selectors, to restore the previous wrapping behaviour for long unbroken text to what it was prior to v3.24.1.

How Has This Been Tested?

Manually tested in local dev environment by loading an API definition with a long unbroken <pre> block, and visually confirmed the wrapping before and after the change (see screenshots).

Screenshots (if appropriate):

How it currently appears since v3.24.1 and prior to merging this PR:

How it previously appeared prior to v3.24.1, and how it will appear after merging this PR:

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]

@scottohara Merged! Thanks for the contribution!