refactor: [hookName].handler in plugins

[sapphi-red]

Description

Moves some plugin[hookName] to plugin[hookName].handler so that we can add filter without a big diff.

This PR has a big diff, but it only moves the hooks under .handler so it shouldn't change any behavior unless the 3rd party plugin / framework calls the plugin manually.

[sapphi-red]

For example, to handle this line:
https://github.com/unocss/unocss/blob/94efa2edc9897dcfb5f40059c11ba22ec9ca0631/packages-integrations/vite/src/modes/global/build.ts#L45

[sapphi-red]

/ecosystem-ci run

[pkg-pr-new]

Open in Stackblitz

npm i https://pkg.pr.new/vite@19586

commit: 273a6d2

[vite-ecosystem-ci]

📝 Ran ecosystem CI on 9ea022a: Open

suite	result	latest scheduled
sveltekit	❌ failure	✅ success
vite-plugin-svelte	✅ success	❌ failure

✅ analogjs, astro, histoire, ladle, laravel, marko, nuxt, previewjs, quasar, qwik, rakkas, react-router, storybook, unocss, vike, vite-environment-examples, vite-plugin-pwa, vite-plugin-react, vite-plugin-react-swc, vite-plugin-vue, vite-plugin-cloudflare, vite-setup-catalogue, vitepress, vitest, vuepress, waku

[patak-dev]

Maybe we should merge this one in Vite 6.3, just to play safe. But I'm ok if you'd like to go with it in a patch to avoid blocking other work.

The diff is massive. Adding a filter would be a common pattern in the future, and I think the boat already sailed but I wonder if it would have been better to keep the hooks as function only and add new properties for each to configure them. It would also have avoided all the indirections to deal with the hook being an object or a function.

transformConfig: {
  filter: /x/,
  order: 'pre'
}
transform(code, id) {
  return transformed(code)
}

[sapphi-red]

Maybe we should merge this one in Vite 6.3, just to play safe. But I'm ok if you'd like to go with it in a patch to avoid blocking other work.

I'm fine with merging in 6.3 👌

The diff is massive. Adding a filter would be a common pattern in the future, and I think the boat already sailed but I wonder if it would have been better to keep the hooks as function only and add new properties for each to configure them. It would also have avoided all the indirections to deal with the hook being an object or a function.

Yeah, maybe that would have made some places easier to handle.

[sapphi-red]

I rebased this PR on top of #19588 as that one should be safe to merge in a patch and this PR conflicts with that one.