This PR migrates `aria` theme keys when migrating from Tailwind CSS v3to v4.While working on improving some of the error messages to get moreinsights into why migrating the JS file changed(#18808), I ran into anissue where I couldn't think of a good comment to why `aria` theme keyswere not being migrated. (Internally we have `aria` "blocked").So instead of figuring out a good error message..., I just went aheadand added the migration for `aria` theme keys.Let's imagine you have the following Tailwind CSS v3 configuration:```tsexport 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:```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-invariants.This could result in slightly different behavior, or different order ofclasses when using `prettier-plugin-tailwindcss`.I don't know how important this is, because before this PR we would justuse `@config './tailwind.config.js';`.Edit: when using the `@config` we override `aria` and extend it, whichmeans that it would be in the expected order 🤔---------Co-authored-by: Jordan Pittman <thecrypticace@gmail.com>