Don't prefix arbitrary classes in peer/group variants

[thecrypticace]

Fixes #11384

This PR stops us from prefixing selectors in the group and peer variants.

For example, given the following HTML:

<div class="tw-group foo">
  <div class="group-[&.foo]:tw-bg-blue-500">
    hello world
  </div>
</div>

The generated selector would contain .tw-foo instead of .foo as the user intended:

.tw-group.tw-foo .group-\[\&\.foo\]\:tw-bg-blue-500

Whereas this should be the selector that is generated

.tw-group.foo .group-\[\&\.foo\]\:tw-bg-blue-500

The reason this happens is because of the design of the addVariant and matchVariant APIs. We build up a one or more selectors that are used to "modify" the resulting utility selector in your CSS. After we've build up the final list of "changes" to a given utility, taking into account all it's variants, we then add prefixes to all classes in the selector (for example, group becomes tw-group, dark becomes tw-dark, underline becomes tw-underline, etc…). The problem with this approach is, at this point, there's no information about what data was derived from arbitrary values and thus no mechanism by which we can say "prefix class .a but not .b" or "prefix .a but not in this one instance".

How is it that we don't know? After all, aren't we matching against the utility?

Take for example this very simplified version of the group variant:

matchVariant("group", (value) => `.group${value} &`)

When matching the utility group-[.bar]:flex and building its rule we then process the foo variant and generate a selector. We place the value .bar in for the value parameter and the function returns .group.bar &.

This is almost as if we had written this:

addVariant("group-[.bar]", `.group.bar &`)

You'll notice here there are no prefixes present yet — this is because, in general, this is handled later in the pipeline for variants.

Now, we explicitly call prefix function for the group class and disable prefixing later in the pipeline for this variant only. This effectively treats the variant as if it were defined like so:

addVariant("group-[.bar]", `.tw-group.bar &`, { respectPrefix: false })

In which case no prefixing is done after building the variant selector because it includes prefixes already.

Now, given that existing user plugins may be defining variants AND those variants have their classes prefixed we can't just disable it wholesale and expect it to be handled in the variant. Additionally, since there's no information about what data was derived from arbitrary values (AND don't even have to be selectors!), to preserve backwards compat while also fixing this we've updated the group and peer variants specifically such that:

1. The relevant group, peer, group/name-here, peer/name-here, etc… classes are prefixed inside the variant function that generates the selector.
2. Exposed an internal-for-now flag for variants called respectPrefix — much like the respectPrefix flag present in addUtilities, matchUtilities, addComponents, etc…
3. Used this flag such that the auto-prefixing that happens later in the pipeline is disabled for this specific variant (like we already do for arbitrary variants — it is infact using the same code path in the end)

This flag is left as internal for now as we want to be sure of the API before we expose it to user-land, work on documentation, etc…