refactor: normalize scripts and commands naming

[patak-cat]

Description

See #5097 for context. That PR explored what would be needed to change serve by dev everywhere, also in the internal API. As plugins are already using config.command === 'serve', it is hard to justify such a breaking change for the ecosystem.

Looks like SvelteKit, Astro and others are using preview as a script name without issues. Maybe this is only a problem when there is a view script? (but that would be already in the hands of the user to arrange). So, this PR changes the current setup from:

vite / vite serve   / pnpm run dev   | the dev server
       vite build   / pnpm run build | the build command
       vite preview / pnpm run serve | the preview server

to:

vite / vite dev     / pnpm run dev     | the dev server ('serve' in the API)
       vite build   / pnpm run build   | the build command
       vite preview / pnpm run preview | the preview server

1. pnpm run serve -> pnpm run preview. This is only used internally and in templates, so we don't need to keep the old script around. We could add the script and log a message for a while but it may be overkill and add noise to the starter templates.

2. dev is introduced as an alias for serve to run the dev server. Current users are used to seeing dev as the script name, and this aligns Vite to other tools in the ecosystem.

3. serve isn't deprecated at this point, because the internal API still uses command === 'serve'. IMO it is best to keep both aliases for the cli.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[antfu]

I am good with these changes. But maybe let's have Evan aware of this first in today's meeting?

[patak-cat]

We decided to move forward with this change. I think we can do it in the next minor even if it doesn't affect core with a breaking change, and only create-vite. I'll update the docs to make it more clear that vite dev and vite serve are equivalent before we merge it.

[patak-cat]

I'll merge this one and then send another PR with a new section for the CLI in the docs. We don't really have a CLI reference at this point so it is hard to see where to properly add this info.