Ensure correct output order of compound selectors

[mgreter]

Fixes #3084, Needs sass/sass-spec#1529

I believe this will fail quite a few spec tests, since it seems we have
some of these as expected outputs!? Lets check what CI returns.

Opened PR to address this in sass-spec.

[mgreter]

I am going to merge this, as I have some time at hand right now to make a release. Even though knowing it will fail CI, but I cant merge the changes in sass-spec. But I'm certain this is an improvement in the right direction; why not emitting correct css selector when we can. Maybe dart-sass comes up with a different approach than to ensure the order on output.

Note to myself: It might be worthwhile to check if we can integrate id and type selectors directly into the CompoundSelector, since css only allows to have one of each per compound selector. I already did the same for hasRealParent. Could save some allocations and might also simplify selector unifying. We may also just have a dedicated vector for each other type (e.g. class, pseudo, etc). This would completely remove the need to sort the children.

[ahorek]

thanks for the release @mgreter !

[mgreter]

No problem @ahorek, still quite a few steps to do for a complete release :)
Currently updating my bindings and then the MSI installers ;)

[nex3]

This breaks compatibility with Dart Sass and with the specified behavior of Sass. Please roll back for now.

If you want to propose a change to the language itself, you need to follow the language change process.

[xzyfer]

Given the discussion in sass/dart-sass#996 we'll need to revert this PR. As @nex3 this is change to the Sass language and makes us non-compliant. Embedders like Node Sass are now blocked on updating LibSass at the risk of introduce incompatible Sass code into the ecosystem.