Fix parallel variant ordering clash

[thecrypticace]

Our ordering for parallel variants could result in some non-deterministic behavior depending on which ones you used and how many utilities were registered before that utility that was using the parallel variant.

This was a side effect of the single bigint sorting scheme we used. We've replaced it with Objects that have a better breakdown of what each section represents. This also means that the bigint numbers we're working with are now MUCH smaller. And, generally, only have to use large numbers for the bitfield used for variants.

This should also result in a minor speedup for the implementation of getClassOrder

[RobinMalfait]

I had an error in my terminal and fixed it and now GitHub Actions is complaining and I'm pretty sure the new code is the correct code. 🤔

[AndyOGo]

Changing the order of generated classes affects precedence.

Why is this not a breaking change?

[RobinMalfait]

@AndyOGo are you running into actual issues? The ordering changes we did shouldn't result in any breaking change unless you were already relying on behaviour that was non-deterministic before and could break the moment you introduced a new content file. A more detailed comment can be found here: #10603 (comment)

If you are running into issues, then could you open an issue with a minimal reproduction repo attached so that we can take a look?

[AndyOGo]

Thanks for your quick reply and sharing that comment @RobinMalfait
I understand your point of view.

I look at it from a CSS spec and semantic versioning viewpoint.
Changing the order of classes, changes the precedence of applying those style rules.
For that reason it's a breaking change.