Rename some selector AST nodes

[xzyfer]

This PR renames most selector AST nodes to better match
their Ruby Sass equivalents. Although we mostly have 1-to-1
mapping between the AST nodes their implementations still
differ significantly. Aligning our selector implementation with
Ruby Sass will the focus upcoming work.

I wasn't able to split the Element_Selector into the respective
Element and Universal selector in Ruby Sass because the
LibSass implementation differed too much.

[coveralls]

Coverage decreased (-0.01%) to 79.083% when pulling d675a84 on xzyfer:feat/cleanup-selectors into dc097fd on sass:master.

[mgreter]

IMO this should be reverted.

a) previously we used the names as given by the css spec
b) comments and variables still refer to the original name (i.e. 97e6200#diff-538f09861f9c693b01b52256a90829c9R1821)
c) sass dart also opted to use the official names: https://github.com/sass/dart-sass/blob/master/lib/src/ast/selector/complex.dart#L25
d) CommaSequence_Selector is really not an intuitive replacement for Selector_List

@xzyfer do you agree on this? Please don't do this already. I'm currently trying to implement a reference counted memory implementation and will do the renaming in that commit. If we do it now on master it will give me a major re-basing headache! Thx!

[xzyfer]

previously we used the names as given by the css spec

In this case being accurate to spec was a hindrance not a help. This change was a made to move use closer to the reference implementation.

comments and variables still refer to the original name

This is easy to fix.

sass dart also opted to use the official names

This is a good argument for eventually doing this. Now is now not the time.

CommaSequence_Selector is really not an intuitive replacement for Selector_List

May be not, but being close the reference implementation has many benefits.

@xzyfer do you agree on this?

I agree we should eventually move to match Dart Sass. IMO it's too early. With 3.5 feature ready to land we should stay close to Ruby Sass until we're committed to making Dart Sass our reference. I don't see this being reasonable until after we ship 3.5.

will do the renaming in that commit

Please don't do this on your branch. Lets keep feature PR focused on one problem at a time.

[chriseppstein]

a lot of the Sass code was written when @nex3 and I were quite naive regarding the official CSS spec. As time has passed we've preferred to match the CSS naming as closely as possible and as @mgreter mentioned it's the preferred naming in the dart impl. I think the css names are more correct than what we use in ruby. honestly wouldn't get too hung up on matching the ruby impl names.

[nex3]

a lot of the Sass code was written when @nex3 and I were quite naive regarding the official CSS spec.

In defense of our past selves, the spec has also changed its terminology to be clearer and more consistent over time.

[mgreter]

@xzyfer I think we do not have the same understanging of what a "hindrance" is. For me changing/renaming the 4 main selector classes is really like learning a new language patois. I've become used to the original names and had to lookup which new name represents what class pretty much every time. That's why one of the first things I did to pull off #2222 was to rename these to their names as they have always been in libsass. I pretty much beg you to return to the original way as it always has been in libsass. I really don't see any benefit to keep it "closer to the reference implementation."! Thanks!

[xzyfer]

The reason for this change was to match the reference implementation. Our selector handling and extends code is in bad shape. I spent a couple weeks trying to resolve some issues with at-root which was slowed significantly but the disparity in selector node names.

I'm in favour of adopting the naming scheme from dart-sass, but against bespoke naming. We're going to be moving closer the reference implementation, especially in light of dart-sass dropping some inconsistent behaviour that we're hacked into libsass.