feat: consolidate syntax highlighting code into standalone plugin

[char0n]

Description

All the syntax highlighting code has been consolidated into single overridable plugin.

Motivation and Context

How Has This Been Tested?

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

[glowcloud]

I'm not seeing any issues in the code, the only thing I was wondering about was the removal of getConfigs from here

swagger-ui/src/core/components/live-response.jsx

Line 78 in f844319

: <Curl request={ curlRequest } getConfigs={ getConfigs } />) }

but I ran the code myself and it looks like we get it there anyway.

Also taking a look at the failing tests, not seeing the issues yet except for having to update the import path in test/unit/components/highlight-code and then to mock getting components for SyntaxHighlighter there.

[char0n]

I'm not seeing any issues in the code, the only thing I was wondering about was the removal of getConfigs from here

If you access a component with getComponent('Name', true), (notice the second true argument), it creates a system container with injected system props. Instead of passing them around, we're using proper redux system container to provide it for us.

[char0n]

Also taking a look at the failing tests, not seeing the issues yet except for having to update the import path in

This has been addressed by additional commits.

[glowcloud]

LGTM!