Allow @custom-variant to redefine built-in variants with proper order.

[Aurailus]

Summary

Adds an "override" property to the object bag passed to Variants.static which forces a variant to get a new order even if it has already been defined. This property is set in index.ts:399 for the @custom-variant rule to allow custom variants to redefine existing variants like active: and have them be properly ordered relative to other custom variants, a.l.a tailwind v3. See #18067 for the motivating regression.

Test plan

Tested using the playground directory. This is a very insignificant (~17 LOC) change which I don't expect to cause many new issues. I can add more robust testing if necessary, just let me know.

[thecrypticace]

The fact that a redefined variant reuses its order was an intentional design decision. This lets someone override hover in place without necessarily affecting how it works relative to the order of other variants. e.g. to tweak or remove the media query for it entirely. If we did not do that then tweaking the selector for a variant could result in things no longer matching the way they did relative to other variants.

For example, if this moved hover to the end:

@custom-variant hover (&:hover);

Then this div would still be blue when clicked when all someone was doing was trying to remove the media query from hover that we ship with by default:

<div class="bg-red-500 hover:bg-blue-500 active:bg-green-500 size-32"></div>

Changing this now could break backwards compatibility with previous 4.x releases in subtle and unexpected ways so I don't see us doing this.

[Aurailus]

@thecrypticace so then how do you propose resolving this in practice? Because this is a regression from the behaviour of Tailwind 3.x. Perhaps a @undef-variant hover; rule or something to undefine a variant so it can get a new order?