Support built-in variants for utilities that include pseudo-elements

[adamwathan]

This PR tries to improve the behavior of our built-in hover, active, focus, and focus-within variant plugins to handle utilities that include pseudo-elements more gracefully.

Prior to this PR, this code:

@variants focus {
  .placeholder-gray-400::placeholder { color: theme('colors.gray.400') }
}

...would generate this CSS:

.placeholder-gray-400::placeholder { color: #CBD5E0 }
.focus\:placeholder-gray-400:focus { color: #CBD5E0 }

Notice that the ::placeholder pseudo-element is completely gone in the focus variant.

This PR changes this behavior to create this output:

.placeholder-gray-400::placeholder { color: #CBD5E0 }
.focus\:placeholder-gray-400:focus::placeholder { color: #CBD5E0 }

This feels much more correct to me at least in this situation, but there is a concern that for some reason using some pseudo-element, someone might actually want this sort of output:

.hover\:foo::before:hover { ... }

...where the hover pseudo-class is added to the pseudo-element itself, rather than the element to which the pseudo-element belongs.

I'm not convinced it's worth trying to solve that problem right now as I don't believe it's possible to give the end user control over how this works without introducing a breaking change, but the new behavior in this PR certainly feels like an improvement over what is currently completely broken.

One thing to note is that the specifics of this implementation actually cause all classes in a selector to receive the pseudo-class prefix:

/* Input */
@variants focus {
  .foo .bar .baz { ... }
}

/* Output */
.hover\:foo:hover .hover\:bar:hover .hover\:baz:hover { ... }

I don't really want people to depend on this and consider it undefined behavior, but can't decide if it's worth trying to detect and throwing an explicit error, mostly because I'm unsure exactly what the heuristic would be for "this is weird don't do this". Would it be any selector that includes multiple classes? An element + a class?

Also, anyone who has authored a variant plugin (like for disabled or something) may want to update their own implementations to behave the way this PR behaves, which makes me wonder if I should try to implement this in a way that makes that automatic, although I'm pretty convinced that couldn't be done in a non-hacky non-bandaid-y way.

Feedback from variant plugin authors on this PR overall would be appreciated.

[adamwathan]

Reminder to myself: think about if this impacts group-hover and if that plugin needs to be updated to accommodate the same thing.