This PR improves the canonicalization process by limiting the bare
values to a certain amount.
Before this PR, whenever we have an arbitrary value, e.g. `left-[6px]`,
then we prefer to use a bare value instead e.g. `left-1.5`. In most
cases, this makes sense.
However, there are places where this doesn't really make sense
(https://x.com/kettanaito/status/2059987396050268589)
- `left-[99999px]` → `left-24999.75 `
The hard part is to figure out _why_ this feels wrong. The `.75` could
feel wrong, but in the `left-[6px]` → `left-1.5`, the `.5` makes sense.
If we reduce that big number to `left-[99996px]` → `left-24999`, then
there is no floating point but it still feels wrong.
One possibility I can think of is to analyze the incoming value and see
if we find certain patterns. All repeating numbers, fun numbers like
`1337`, common numbers most programmers know such as `720px`, `1280px`,
etc.
But instead of that, I think it's more reasonable to limit the bare
value such that the `px` based value doesn't exceed a big number. We can
improve the logic if there are other cases that don't really make sense.
The biggest value we have in our default theme is `--breakpoint-2xl:
96rem`, which is equivalent to `1536px`.
So I think any bare value that results in a value `<= 1536px` should
probably be fine.
In this case, `left-[99999px]` would stay as `left-[99999px]`, but
`left-[6px]` is still converted to `left-1.5`.
Note: this is only happening for arbitrary values being converted to
bare values _if_ they use the `--spacing` variable internally.
Values such as `z-[99999999999]` will still be converted to
`z-99999999999`, since the intent is still clear.
## Test plan
1. Added new tests for these limitations
2. Other existing tests still pass
6b43b6400a