This PR is similar to and a follow up of #18815, but this time to
migrate the `data` theme keys.
Let's imagine you have the following Tailwind CSS v3 configuration:
```ts
export default {
 content: ['./src/**/*.html'],
 theme: {
 extend: {
 data: {
 // Automatically handled by bare values
 foo: 'foo',
 // ^^^ ^^^ ← same names
 // Not automatically handled by bare values
 bar: 'baz',
 // ^^^ ^^^ ← different names
 // Completely custom
 checked: 'ui~="checked"',
 },
 },
 },
}
```
Then we would generate the following Tailwind CSS v4 CSS:
```css
@custom-variant data-bar (&[data-baz]);
@custom-variant data-checked (&[data-ui~="checked"]);
```
Notice how we didn't generate a custom variant for `data-foo` because
those are automatically handled by bare values.

This PR is a follow up of #18815 and #18816, but this time let's migrate
the `supports` theme keys.
Let's imagine you have the following Tailwind CSS v3 configuration:
```ts
export default {
 content: ['./src/**/*.html'],
 theme: {
 extend: {
 supports: {
 // Automatically handled by bare values (using CSS variable as the value)
 foo: 'foo: var(--foo)', // parentheses are optional
 bar: '(bar: var(--bar))',
 // Not automatically handled because names differ
 baz: 'qux: var(--foo)',
 // ^^^ ^^^ ← different names
 // Custom
 grid: 'display: grid',
 },
 },
 },
}
```
Then we would generate the following Tailwind CSS v4 CSS:
```css
@custom-variant supports-baz {
 @supports (qux: var(--foo)) {
 @slot;
 }
}
@custom-variant supports-grid {
 @supports (display: grid) {
 @slot;
 }
}
```
Notice how we didn't generate a custom variant for `data-foo` or
`data-bar` because those are automatically handled by bare values.
I also went with the longer form of `@custom-variant`, we could use the
single selector approach, but that felt less clear to me.
```css
@custom-variant supports-baz (@supports (qux: var(--foo)));
@custom-variant supports-grid (@supports (display: grid));
```
---------
Co-authored-by: Jordan Pittman <thecrypticace@gmail.com>