Refactor doc module implementations

Problem/Motivation

The doc module routes are currently statically defined for the default supported modules. This is limiting and results in redundant classes naming. These should be refactored into dynamically generated routes using plugins.

Proposed resolution

Plugins

In #2874877: Refactor OpenApiController, we introduced plugins for managing generators. Implemented a plugin for docs modules could provide dynamic functionality and allow other ui type modules to be built around the openapi specs.

Routes

Using plugins for generators allowed us to convert the routes for the downloads into a single dynamic route with a dynamic param. Using plugins for the doc uis we can achieve a similar simplicity. A single route could be provided by core, which would take both a generator and a doc plugin and produce the same result.

The only challenge presented by the current implementation is that the SwaggerUi module provides two different implementations. For Jsonapi, it provides a single url for details on all endpoints. However, for REST it provides a url for each for each of the available entity types. This means that a plugin type design is not available here.

This per entity implementation however is an interesting thought. Since we already allow filtering of the download doc based upon entity, this functionality can be preserved by allowing the same filter params to be added to the generic doc for the rest+swagger docs ui. That filter chunk can then be passed to the download controller and the output can be used to display the docs. This allows us to generate the range of doc pages while limiting the number of routes that we are generating. This also allows us to extend this function into the json api docs. Additionally if we implemented this in a top level controller, we could also extend this into the reDoc module as well.

Remaining tasks

1. Replace Doc urls with unified route, using the OpenAPI UI module.
2. Remove the ReDoc and Swagger modules, as they have been replaced.
3. Developer installation steps to remove the old modules and install the new modules, if they are present. If not, we want to alert the user and fail the database update the admin either installed the new library or uninstalls the module via another method.
4. Publish a Change Record and Release to remove this feature.

User interface changes

We will be eliminating the swagger_ui.rest.list route and replacing it with extended filtering functionality. We may wish to provide either a similar listing page or to provide a filter option on the actual page to allow the user to select the filter params for the ui. This will as a result eliminate the need for #2874891: Allow filtering doc pages per resource.

API changes

This will not result in any critical changes to the api, but will provide more extensible resources for module developers to extend the openapi functionality.