Simplify deployment: unify dstack and meta-dstack workflows

首先阅读 kms/dstack-app/deploy-simple.sh 和 deploy-to-vmm.sh，然后将它们的输入与 meta-dstack's build.sh 的 hostcfg 和 dl 工作流进行比较。当部署入口点、目录布局、guest-image 获取方式以及 development 和 production 路径按描述统一，同时从源代码构建 OS image 仍为可选项时，即表示完成。

Problem

Setting up dstack currently requires understanding two repositories with different workflows:

1. Two repos required for basic deployment

• meta-dstack: Config generation (build.sh hostcfg) and image download (build.sh dl)
• dstack: Components and deploy scripts (kms/dstack-app/deploy-*.sh)

New users must clone both repos and understand their relationship.

2. Inconsistent paths between dev and production

Same artifacts, different acquisition paths.

3. Deploy scripts in unexpected location

• kms/dstack-app/deploy-simple.sh and deploy-to-vmm.sh deploy to VMM
• These aren't KMS-specific—they're general CVM deployment scripts
• Expected location would be top-level deploy/ or similar

4. Guest image acquisition differs

• Dev: Requires meta-dstack checkout, then ../build.sh dl
• Prod: Direct download from https://github.com/Dstack-TEE/meta-dstack/releases

Both get the same tarball via different paths.

Impact

• Steeper learning curve for new operators
• Documentation must explain two different workflows
• Easy to get confused about which repo/script to use
• Friction when switching between dev and production setups

Suggested Direction

• Single entry point for deployment (no meta-dstack required for normal use)
• Unified deploy/ directory structure in dstack repo
• meta-dstack becomes optional (only needed for building OS image from source)
• Config templates with sensible defaults

This is a tracking issue for discussion. Implementation would be a larger effort.