Fix migrating `mt-[0px]` to `-mt-[0px]` instead of the other way around (#18154)

I was testing to upgrade tool on various random projects just to see how
it behaves. Then I noticed an odd migration...

This PR fixes an issue where the upgrade tool accidentally migrated
classes such as `mt-[0px]` to `-mt-[0px]`. The reason for this is
because we are trying to find a replacement, and the computed signature
for both of them are exactly the same.

- `mt-[0px]` translates to:

   ```css
   .x {
     margin-top: 0px;
   }
   ```

- `-mt-[0px]` translates to:

   ```css
   .x {
     margin-top: calc(0px * -1);
   }
   ```

   Which in turn translates to

   ```css
   .x {
     margin-top: 0px;
   }
   ```

   Notice that this is `0px`, not `-0px`.

Internally we use the roots of functional utilities to find
replacements. For intellisense purposes we typically show negative
versions before positive versions. This then means that we will try
`-mt-*` before `mt-*`. Because of the signature above, the `mt-[0px]`
was translated into `-mt-[0px]`.

We could solve this in a few ways. The first thing we can try is to make
sure that the signature is not the same and that `-mt-[0px]` actually
translates into `-0px` not `0px`.

This would solve our problem of the accidental migration. However, if we
_just_ sort the functional utilities roots such that the positive
versions exist before negative version and rely on the fact that
`-mt-[0px]` has the same signature. Then it also means that by doing
that we can migrate `-mt-[0px]` into `mt-[0px]` which is even better
because it's the same result and shorter.

## Test plan

1. Added a test to verify that `mt-[0px]` does not get migrated to
`-mt-[0px]`.
2. Added a test to verify that `-mt-[0px]` does get migrated to
`mt-[0px]`.