Option to configure Plugins and Presets via Docker Env Variables

[eisclimber]

Option to configure Plugins and Presets via Docker Env Variables

Description

This change allows customization of the swagger-ui image without having to reimplement the templating logic for the swagger constructor.

This change just connects the already implemented functionality to docker environment variables.

Motivation and Context

A good example why this is needed, is customizing the logo via plugin as described here.
While the script defining the plugin can be loaded using a custom index.html, a custom swagger-initializer.js``would either be overwritten or not be templated at all.

The LAYOUT parameter is not included in this PR, as it is already implemented in the same way, but simply missing from the documentation (See #10029).

How Has This Been Tested?

The change was tested by running the adjusted Dockerfile with different values for said environment variables (including omitting them).
It was also tested with a custom image with a custom logo, as mentioned above.

Checklist

My PR contains...

• [ x ] 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)
• [ x ] Improvements (misc. changes to existing features)
• [ x ] 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).
• [ x ] are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• [ x ] My changes require a change to the project documentation.
• [ x ] If yes to above: I have updated the documentation accordingly.

Automated tests

• [ x ] 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.
• [ x ] All new and existing tests passed.