Migrate aria theme keys

[RobinMalfait]

This PR migrates aria theme keys when migrating from Tailwind CSS v3 to v4.

While working on improving some of the error messages to get more insights into why migrating the JS file changed (#18808), I ran into an issue where I couldn't think of a good comment to why aria theme keys were not being migrated. (Internally we have aria "blocked").

So instead of figuring out a good error message..., I just went ahead and added the migration for aria theme keys.

Let's imagine you have the following Tailwind CSS v3 configuration:

export default {
  content: ['./src/**/*.html'],
  theme: {
    extend: {
      aria: {
        // Built-in (not really, but visible because of intellisense)
        busy: 'busy="true"',

        // Automatically handled by bare values
        foo: 'foo="true"',
    //  ^^^   ^^^            ← same names

        // Not automatically handled by bare values because names differ
        bar: 'baz="true"',
    //  ^^^   ^^^            ← different names

        // Completely custom
        asc: 'sort="ascending"',
        desc: 'sort="descending"',
      },
    },
  },
}

Then we would generate the following Tailwind CSS v4 CSS:

@custom-variant aria-bar (&[aria-baz="true"]);
@custom-variant aria-asc (&[aria-sort="ascending"]);
@custom-variant aria-desc (&[aria-sort="descending"]);

Notice how we didn't generate a custom variant for aria-busy or aria-foo because those are automatically handled by bare values.

We could also emit a comment near the CSS to warn about the fact that @custom-variant will always be sorted after any other built-in variants.

This could result in slightly different behavior, or different order of classes when using prettier-plugin-tailwindcss.

I don't know how important this is, because before this PR we would just use @config './tailwind.config.js';.
Edit: when using the @config we override aria and extend it, which means that it would be in the expected order 🤔