chore: rework CSS extraction

[layershifter]

This PR refactors Webpack plugin for CSS extraction.

Before

We use the same approach as CompiledCSS: we create a new cacheGroup in optimization.splitChunks and force all generated CSS files by us to go there.

As a result we will get a single asset (CSS file) that we can process and sort rules. This works, but this approach requires optimization.splitChunks to be enabled. One of our key partners has this setting disabled in dev environment: all try outs to enable it were not successful.

This approach also prevents all attempts to implement chunks splitting support and avoid a single CSS file.

After

TL;DR Does the same, works differently ¯_(ツ)_/¯

The key difference is that we don't use optimization.splitChunks and moving CSS files to a target chunk.

Initial attempt

Inspired by atlassian-labs/compiled#724. All processing was done during .processAssets stage and it worked: we got a CSS file per a chunk (if it contained makeStyles calls) and I was able to extract rules from it to a dedicated chunk.

But:

• If a chunk contained only Griffel's CSS after processing we got an empty file, for example:

  - griffel.css (contains all CSS)
  - chunk.css (became empty file)
  - async-chunk.css (became empty file)
  

• These empty files could not be removed (via compilation.deleteAsset()) as mini-css-extract-plugin will register async chunks in JS runtime and these assets will fail to load.
• Whatever modifications to assets we will do - we should do them before .runtimeRequirementInTree (undocumented Webpack hook) otherwise chunks that have empty CSS could be registered in JS runtime 💣

Implementation in this PR

After multiple attempts to do something with assets I realized that .processAssets is too late to transfer CSS between chunks. The problem that at any stage before .runtimeRequirementInTree we don't have assets - we operate with modules (not really well documented). Simple explanation: an asset is a concatenated set of modules.

On .afterChunks (again undocumented, happens after a chunk graph gets generated and modules were collected):

• we attach a custom chunk to main entrypoint
• we move all modules produced by mini-css-extract-plugin to that chunk (if they contain CSS produced by Griffel)

On .processAssets we are in the same condition actually as currently: all CSS modules produced by Griffel were moved to a dedicated chunk -> this chunk has a single CSS file -> we sort rules in it ✅

[github-actions]

📊 Bundle size report

_{🤖 This report was generated against e242ccaaa99b08bbb0cfdfdb9fcd2db802c33fc2}

[layershifter]

As we don't import/require @griffel/webpack-loader anywhere - Nx fails to detect it as a dependency.

[layershifter]

Have been in a wrong spot 🤦

[ling1726]

is the main entrypoint guaranteed to be the first entrypoint in compilation.entrypoints ?

[ling1726]

actually, what if webpack is configured with multiple entrypoints?

[layershifter]

It's a good question. In all scenarios that I currently tested attaching to main entrypoint was enough. So, I don't have answer if it's good or bad. Currently works.