Can't use arbitrary value as Vite mode to build non-production code

### Environment info

**firebase-tools:** 13.16.0

**Platform:** Linux

### Test case

Any Vite based project which uses modes.

### Steps to reproduce

We disable AppCheck in local dev environments. We only enable it in prod or staging environments.
```
if (!dev) initializeAppCheck();
```
We also store FB configs in .env files for prod and staging FB projects (`.env.production` and `.env.development`). Building production code is fine, `firebase deploy` calls `vite build --mode production` by default.
**But how do we build staging code?**
I checked the code of firebase-tools and it seems we can use `FIREBASE_FRAMEWORKS_BUILD_TARGET` to override build target, so let's set it to `development`. Now comes the problem: when `FIREBASE_FRAMEWORKS_BUILD_TARGET` is set to `development` it also causes `NODE_ENV` to be `development` which, in its own turn, causes `dev` from `$app/environment` to be `true` (SvelteKit uses [benmccann/esm-env](https://github.com/benmccann/esm-env)). So now we have code built for staging env with `dev` set to `true`. OK, let's try setting `FIREBASE_FRAMEWORKS_BUILD_TARGET` to `staging`. Unfortunately it's not possible because this variable only supports two values `production` and `development` and `firebase deploy` bails out if anything else is supplied.
Eventually, we might find a workaround by once again monkey-patching `src/frameworks/vite/index.ts` but the problem is wider. What if someone has multiple Vite modes like: `production-us`, `production-eu`, `staging-us` and `staging-eu`? How do we pass arbitrary values to `vite build --mode`? Or what if someone has additional build step after the code is built but before it's deployed?
The problem here is that `firebase deploy` not only deploys, but also builds the code. It tries to do this auto-magically. And while doing so it takes away some freedom from the developers. After many rounds of discussions and patches, It might, eventually, get it right, but this is going to be another layer of abstraction to deal with.
My proposal is simple: don't build the code in `firebase deploy`. Let developers build the code correctly and just deploy it. It's a win-win situation: firebase-tools devs have less work to do, and fb-tools users have less things to figure out.
As in Unix philosophy:
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

### Expected behavior

`dev` is `false`

### Actual behavior

`dev` is `true`