Forward modifier from has-* and not-* variants to compounded variant

[RobinMalfait]

This PR fixes an issue where using a modifier in combination with has-* or not-* doesn't work as expected.

If you have the following HTML:

<div class="group/parent" data-visible="">
  <div class="group-data-visible/parent:text-red-500"></div>
</div>

Then the following CSS is generated:

.group-data-visible\/parent\:text-red-500:is(:where(.group\/parent)[data-visible] *) {
  color: var(--color-red-500);
}

But if you want to use it with not-*, then nothing is being generated:

<div class="group/parent" data-visible="">
  <div class="not-group-data-visible/parent:text-red-500"></div>
</div>

/* <EMPTY> */

But with this PR, we will forward the modifier parent from the not variant, to the group variant, so the following CSS is generated:

.not-group-data-visible\\/parent\\:text-red-500:not(:where(.group\\/parent)[data-visible] *) {
  color: var(--color-red-500);
}

This is also implemented for has-*

[thecrypticace]

It feels super weird to me to mutate the variant we're getting. Could this be handled in parseCandidate or something?

[thecrypticace]

Though I guess we'd need some additional metadata for that to work right. I guess as long as this isn't guaranteed to "break" non-compounded versions of the same variant (do we have a test for that?) then it's probably fine.

[thecrypticace]

Yeah the mutation breaks stuff:

[RobinMalfait]

Handling it during parsing might break things as well, especially when we re-print a candidate.

[thecrypticace]

hopefully can fix this w/o too much hassle

[RobinMalfait]

This is more correct, but feels so wrong in this spot

[thecrypticace]

yeah agree it does feel wrong 🤔

Could in theory add a forwardsModifier() method to Variants and control it from there? Gonna think on this some