Optimize federation of shared PF5 code for dynamic plugins

Once PR #12983 gets merged, Console application itself will use PatternFly v5 while also providing following PatternFly v4 packages as shared modules to existing dynamic plugins:

• @patternfly/react-core
• @patternfly/react-table
• @patternfly/quickstarts

Above mentioned PR will allow dynamic plugins to bring in their own PatternFly code if the relevant Console provided shared modules (v4) are not sufficient.

Let's say we have a dynamic plugin that uses PatternFly v5 - since Console only provides v4 implementations of above shared modules, the plugin would bring in the whole v5 package(s) listed above.

There are two main issues here:

1. CSS consistency

• Console application should be responsible for loading all PatternFly CSS, including older versions (like v4) for use with existing plugins.
• Plugins should not bring in their own PatternFly CSS in order to avoid styling related bugs.

2. Optimal code sharing

• Treating entire PatternFly packages as shared modules yields very big JS chunks, which means more data to load over the network and evaluate in the browser.
• Instead of per-package, PatternFly v5 code should be federated per-component.

This story should address both issues mentioned above.

Acceptance criteria:

• webpack generated Console plugin does not bundle PatternFly CSS
• webpack generated Console plugin treats individual PatternFly v5 components as shared modules