CSS bundling support : creates a parallel deps graph just for styles

[AurelienStebe]

Description

This creates a virtual "style" JS file for each Marko node and redirects all CSS imports to them.
The resulting bundle contains N pages entry points and N styles entry points. Both dependency trees go through the same bundling process and any Rollup CSS plugin can extract the actual CSS asset files from the resulting "styles" deps tree.

Motivation and Context

This actually doesn't directly fix the issue of associating the resulting CSS assets to their pages entry points.
It does allow "rollup-plugin-styles" in particular to properly code-split the CSS and chunk it according to "manualChunks".

Since, the virtual "styles" have clear entry points with an "id" derived from the pages "id", then "facadeModuleId" can be used to link them. It would be better to use the "name" property created by the server-side plugin, which can ensure those are unique. I used the "options" hook to get them from the Rollup "input", but that is incompatible with the idea of "emitting" entry pages as the server-side detects them. So I changed the implementation yesterday, but it seems that there is no other way to get the "name" before the "generateBundle" hook. The server-side should probably emit the virtual "style" chunk also (see line 124).

The CSS assets corresponding to pages entry points would then have a filename derived from the pages "name" also, still unique. However, CSS assets corresponding to auto code-split chunks can have name collision (same base "name", but different hash, so impossible to trace) if they each come from CSS files with the same filename, but in different folders.

For this, 2 possible PR to send to "rollup-plugin-styles" :

• Add the generated asset filename to the chunk imports like "rollup-plugin-css-chunks" : https://github.com/domingues/rollup-plugin-css-chunks/blob/0e8c181701d91bb406411ce4abaaaf144b000164/index.ts#L194
  Advantage : already implemented in 1 of the 3 Rollup CSS plugins

• Use the new Rollup "meta" property specially created for plugins : https://rollupjs.org/guide/en/#custom-module-meta-data
  Advantage : is probably less likely to break someone else's build

Finally, there is the option to use the "generateBundle" hook to replace the "style" chunks "filename" and "code" with the values from the actual CSS assets (and remove the assets from the bundle). Result, no useless JS files to cleanup and the logic to explore the JS and the CSS deps graph inside the bundle is exactly the same. The difference is that the JS graph can be explored to add eventual "preconnect" or "prefetch", but the CSS graph must be explored because "@import" are a bad idea. Disadvantage, but very small one I think, the brand new "validate" Rollup option is not gonna like that : rollup/rollup#3952

By the way, "rollup-plugin-css-chunks" also works, but it doesn't auto code-split and duplicates CSS between pages (it does respect "manualChunks" and has the option to inline "@import", though).
As stated before, "rollup-plugin-postcss" can only output a single CSS asset, so no problem with the "pages" association.