This PR improves the developer experience when trying to use `theme(…)`
options on an import.
Today, if you want to use Tailwind CSS, you can import it as:
```css
@import "tailwindcss";
```
But if you want to use any of the `theme(…)` options, like the `static`
theme option, then you had to use this instead:
```css
@layer theme, base, components, utilities;
@import 'tailwindcss/theme' layer(theme) theme(static);
@import 'tailwindcss/preflight' layer(base);
@import 'tailwindcss/utilities' layer(utilities);
```
In this scenario you have to be careful, because the `layer(…)` _must_
be the first option after an import (according to the spec). So if you
use `@import 'tailwindcss/theme' theme(static) layer(theme);` then
that's not going to work either.
This PR solves that by allowing you to use the `theme(…)` options
directly on the `@import` statement:
```css
@import 'tailwindcss' theme(static);
```
The only edge case is when you want to use `theme(reference)`. A typical
use case is for projects with `<style>` blocks where you want to
_reference_ the CSS variables from the theme.
If you use `@import 'tailwindcss' theme(reference);`, then all `@theme`
blocks will be references and you can reference theme values. This is
good. The bad part is that `@import 'tailwindcss';` also includes
preflight CSS. This means that we will import the preflight CSS for
every `<style>` block. This is probably not what you want.
The solution is to use `@reference 'tailwindcss';` instead which strips
all of that information and only gives you access to CSS variables.
This PR also makes sure that if you use `theme(reference)` on an import
that we still throw an error and suggest you use `@reference` instead.
This is not a breaking change because right now if you use `@import`
with `theme(…)` options it will already throw an error.
### Test plan:
1. Added dedicated tests to make sure we don't throw anymore.
2. Added test to make sure that we _do_ throw when using
`theme(reference)` on an import.