Use css-tree parser for wrapping theme styles

[strarsis]

Description

This PR adds the CSSTree parser for wrapping the theme styles into a styles wrapper.

How has this been tested?

I tested this on my local WordPress site.
Apparently there aren't tests (except some traversal stuff that had been only internally used anyway).

Edit:

• What exactly is the purpose of baseUrl passed in the rules objects to the method?
• Test added with (complex) input and expected output CSS.

Types of changes

• Because a custom CSS parser is currently used, parse errors can occur, as in url([...]url([...])[...]) causes styles wrapping to fail completely (although valid CSS) #21569.
• CSSTree is a native JavaScript CSS parser that is already used in other major projects like svgo and csso, hence it should handle all CSS fast and well.
• CSSTree can also generate sourcemaps and even reuse existing sourcemaps. With some API changes it should be possible to add sourcemap support in Gutenberg, which means that developers can still see from where the injected styles came from
  (PoCs here: https://codepen.io/strarsis/pen/RwWRqZv and also https://codesandbox.io/s/busy-williamson-r1frp). (Not implemented with this PR, but CSSTree adds the foundation for it).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[youknowriad]

Nice PR, I'll plan to take a look at it in the upcoming days.

[strarsis]

@youknowriad: I also added a test for transforming the styles.
What is the purpose of the baseUrl parameter (that is never set in all the runs I tried with the transform function)? Is this for rewriting all style URLs in the CSS?

(The test can be run individually using this invocation: ./node_modules/.bin/jest --config test/unit/jest.config.js ./packages/block-editor/src/utils/transform-styles/test/transform-styles.js)

[youknowriad]

What is the purpose of the baseUrl parameter (that is never set in all the runs I tried with the transform function)? Is this for rewriting all style URLs in the CSS?

Yes, if I remember properly, it was used to transform relative and absolute URLs in CSS rules. I'm not sure how it evolved though.

[strarsis]

@youknowriad: Ah, found the test for this:

• https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/utils/transform-styles/transforms/test/url-rewrite.js
• https://github.com/WordPress/gutenberg/blob/master/packages/block-editor/src/utils/transform-styles/transforms/test/__snapshots__/url-rewrite.js.snap

Hm, I will reuse the existing tests, the build is currently failing because of some newlines or such, hm...

[strarsis]

@youknowriad: Based on the tests, support for baseURL has been added.
One thing though: URLs that start with a slash (e.g. /image/test.jpg) are called "absolute" URLs in the test, which is incorrect as those URLs are also relative URLs, they are just normalized ("flattened", no .. inside). The WHATWG (native) URL class is used, which can take proper care of all kinds of URLs, including data-URLs and automatically rebases and normalizes them.

[noahtallen]

Bad rebase? ;)

[strarsis]

@noahtallen: Yes, should I try to fix it or make a new PR?

[noahtallen]

I think you should be able to fix it in the current PR. I would probably try:

1. Locally update your fork's master branch to current Gutenberg master branch
2. Locally, with this branch checked out, run git rebase master locally
3. Then git push --force to get those changes to this PR

[noahtallen]

Oh, when you are rebasing, do git rebase -i master to do an interactive rebase. It looks like you might need to remove commit 068183e from the PR before you push it

[strarsis]

@noahtallen: Well, it turned out that some implementation details were missing. For preserving the original test structure I created a new PR that supersedes this one: #21936