guest: support development-only no-TEE VMs

[h4x3rotab]

Summary

• add development-only no-TEE VMs for local testing
• reuse the KeyProvider::None path for temporary local app keys and reject certificate and attestation APIs
• signal no-TEE boot through QEMU fw_cfg without changing the image command line
• disable disk encryption and reject TEE-dependent compose settings
• document the maintainer workflow in CONTRIBUTING.md

Safety

No-TEE mode requires key_provider=none and explicitly rejects gateway use and TEE requirements. TEE mode cannot change after VM creation, and no-TEE guests always boot with storage encryption disabled. Normal TEE boots retain the existing fatal check when no TEE guest device is available.

Tests

• cargo test -p dstack-vmm -p dstack-util -p dstack-guest-agent -p cert-client from dstack/
• cargo clippy -p cert-client -p dstack-guest-agent -p dstack-util -p dstack-vmm --all-targets from dstack/
• npm run build in dstack/vmm/ui
• bash -n os/common/rootfs/dstack-prepare.sh
• QEMU accepts -fw_cfg name=opt/dstack/no-tee,string=1
• python3 -m py_compile dstack/vmm/src/vmm-cli.py
• prek run --files CONTRIBUTING.md os/common/rootfs/dstack-prepare.sh

[kvinwang]

As an alternative approach for no-TEE development VMs, I opened #780.

Instead of branching core guest security paths on a no_tee flag, it keeps the production guest code path and simulates the TEE ABI (configfs-tsm quotes, RTMR, CCEL) via a FUSE-based dstack-tee-simulator on development images only. The goal is to avoid scattering if no_tee checks through prepare/key/encryption/attestation code, and to let local no-TEE boots exercise most of the real production path.

Would you prefer we pursue #780 over this PR, or is there something in #766 that still works better for your use case? Happy to discuss either way.