Introduce EnvVarInputs to resolve the env vars given to apps

[cprecioso]

Description

Extracts the resolution of the env vars we give to the client and server apps into a new Wasp.Cli.Util.EnvVarInputs module, and refactors the existing wasp build start env var handling on top of it. No functional changes intended.

• An EnvVarInput names a place an app's env vars can come from: the environment Wasp itself runs in (Inherit), a CLI option like --server-env (FromFlag), a dotenv file passed via --server-env-file (FromFileArgument), or a project dotenv file like .env.server (FromProjectFile).
• resolveEnvVarInputs reads all the inputs and merges them with the wasp-owned env vars, failing if any source tries to override a wasp-owned var. Because every input carries a user-facing label, the error now points at the offending source (e.g. PORT (set in .env.server)).
• wasp build start parses its --{client,server}-env/--{client,server}-env-file options directly into EnvVarInputs and resolves them through the new module. This replaces Wasp.Env.overrideEnvVars and the ad-hoc merging helpers in BuildStart.Config.

The Inherit and FromProjectFile inputs are exercised only by unit tests for now; the next PR in the stack uses them to share this same resolution between wasp start and wasp build start.

The only user-visible difference is the wording of the error when a user sets a wasp-owned env var, which now includes where they set it.

Part of the dev-server ports stack (4/7): hints system → AppSpec from compiler → Apps datatype → EnvVarInputs refactor → Wasp-owned ports → port flags → port auto-selection.

Type of change

• 🔧 Just code/docs improvement
• 🐞 Bug fix
• 🚀 New/improved feature
• 💥 Breaking change

Checklist

• I tested my change in a Wasp app to verify that it works as intended.

• 🧪 Tests and apps:

  • I added unit tests for my change.
  • (if you fixed a bug) I added a regression test for the bug I fixed.
  • (if you added/updated a feature) I added/updated e2e tests in examples/kitchen-sink/e2e-tests.
  • (if you added/updated a feature) I updated the starter templates in waspc/data/Cli/templates, as needed.
  • (if you added/updated a feature) I updated the example apps in examples/, as needed.
    • (if you updated examples/tutorials) I updated the tutorial in the docs (and vice versa).

• 📜 Documentation:

  • (if you added/updated a feature) I added/updated the documentation in web/docs/.

• 🆕 Changelog: (if change is more than just code/docs improvement)

  • I updated waspc/ChangeLog.md with a user-friendly description of the change.
  • (if you did a breaking change) I added a step to the current migration guide in web/docs/migration-guides/.
  • I bumped the version in waspc/waspc.cabal to reflect the changes I introduced.