Using user's vite.config.ts as entry point POC

[infomiho]

Description

This is POC of one of the approaches to give more control over Vite to the user. Not a real PR that needs to be reviewed and merged. This PR will be deleted afterwards.

What's in the POC

• Modified the web-app to use the user's config directly (this means user's config is the real config but web-app is still the entry point, we are still a framework)
  • vite CLI is invoked with ../../../vite.config.ts flag
  • web-app's vite.config.ts no longer imports user's config and merges with Wasp's config
  • User's config now includes the wasp() plugin which contains all the important options
• Moved all Vite config options (e.g. client app port, react() plugin etc.) to the wasp() plugin
  • The plugin applies all the same Wasp-specific options and it's still templated
  • The plugin accepts options to configure the react() plugin
  • The plugin extends the test options for Vitest to ignore .wasp/**/* if Vitest is used from user-land
  • The plugin is located in the SDK and users import it from wasp/client/vite and use in the vite.config.ts:

    import { defineConfig } from "vite";
    import { wasp } from "wasp/client/vite";
    
    export default defineConfig({
      plugins: [wasp()],
    });

• Moved Vitest to user-land (this is probably not 100% necessary to do, but I was cleaning up and did this at the same time, in the real PR this would come as a separate effort)
  • Removed dependencies related to Vitest
  • Deleted wasp test client command
  • Deleted Wasp-specific test helpers (recreated them in kitchen-sink, not sure what would be the best way to ship these helpers, as part of the docs?)
  • Setup Vitest in user-land with latest Vitest 4 (and not Vitest 1 which we had in Wasp)

Part of #3135 #3472