Vite: Don't track candidate changes for Svelte <style> tags

[philipp-spiess]

Closes #14965

This PR changes the way we register Tailwind CSS as a Svelte preprocessor when using the Vite plugin. The idea is to reduce the bookkeeping for interacting with CSS inside <style> tags so that we have a more consistent behavior and make sure the Svelte-specific post-processing (e.g. local class mangling) works as expected.

Prior to this change, we were running Tailwind CSS as a Svelte preprocessor and then we would transform the file again when necessary inside the Vite transform hook. This is necessary to have the right list of candidates when we build the final CSS, but it did cause some situation to not apply the Svelte post-processors anymore. The repro for this seemed to indicate a timing specific issue and I did notice that specifically the code where we invalidate modules in Vite would cause unexpected processing orders.

We do, however, not officially support rendering utilities (@tailwind utilities;) inside <style> tag. This is because the <style> block is scoped by default and emitting utilities will always include utilities for all classes in your whole project. For this case, we highly recommend creating as separate .css file and importing it explicitly.

With this limitation in place, the additional bookkeeping where we need to invalidate modules because the candidate list has changed is no longer necessary and removing it allows us to reduce the complexity of the Svelte integration.

Test Plan

svelte.test.plan.mov

Not seen in the test plan above I also tested the pnpm build --watch step of the Vite project. This does require the pnpm preview server to restart but the build artifact are updated as expected.

[philipp-spiess]

Want to make it so that the root created for svelte files only scans the template file