Simplify deployment: unify dstack and meta-dstack workflows

## 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

| Task | Dev Deployment | Production Deployment |
|------|----------------|----------------------|
| Get guest image | `../build.sh dl 0.5.5` | Direct GitHub release download |
| Generate configs | `../build.sh hostcfg` | Manual or embedded in compose |
| Deploy KMS | Run binary on host | `kms/dstack-app/deploy-*.sh` |

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.