Use Lightning CSS in the PostCSS Plugin (#10399)

* bump lightningcss

* use `lightningcss` in the main PostCss Plugin

* use lightningcss in our custom matchers

Now that we are using `lightningcss` and nesting in the new `oxide`
engine, the generated output _will_ be different in the majority of test
cases.

Using a combination of `prettier` and `lightningcss` will make the
output consistent.

The moment we are fully using the `oxide` engine, we can drop
`lightningcss` or `prettier` again to improve the performance of the
tests.

* update tests to apply `lightningcss` related changes

* update changelog

* add `lightningcss` and `browserslist` as dev dependencies to stable package.json

* only use `lightningcss` in tests (without prettier)

We will only fallback to prettier if lightningcss fails somehow.

* apply side effect chagnes due to only using lightningcss for tests

* make CI happy (integration tests)

Apply changes to integration tests now that we are using lightningcss

* transform `lightningcss` for Node 12 when running tests

* run prettier on failing tests for `toMatchFormattedCss`

This will result in better diffs because diffs are typically per block
and/or per line. But lightningcss will simplify certain selectors and
the diff won't be as clear.

We will only apply the prettier formatting for failing tests in the diff
view so that diffs are cleaner and we don't pay for the additional
prettier calls when tests pass.

integrations/postcss-cli/tests/integration.test.js

@@ -222,11 +222,9 @@ describe('watcher', () => {
       css`
         .btn {
           border-radius: 0.25rem;
-          padding-left: 0.5rem;
-          padding-right: 0.5rem;
-          padding-top: 0.25rem;
-          padding-bottom: 0.25rem;
+          padding: 0.25rem 0.5rem;
         }
+
         .font-bold {
           font-weight: 700;
         }