Adopt RFC 8785 (JCS) for canonical compose hash calculation

[Leechael]

Problem

Right now, the same appcompose can hash differently depending on how the JSON is formatted - whitespace, key order, indentation, you name it. This makes verification a pain for devs trying to prove their docker-compose is actually running in a TEE.

Proposal

Use RFC 8785 - JSON Canonicalization Scheme for compose hash calculation.

Rollout

Phase 1 - SDK & Docs

• Add JCS hash calculation to the SDK
• Update docs explaining how it works and how the compose hash is built from each component
• No breaking changes yet

Phase 2 - Migration

• Make JCS the default in SDK
• Provide tooling to verify/convert existing files

Phase 3 - Enforcement

• Require JCS-canonical hashes in a future release
• Reject non-canonical submissions

Separate hashes for docker_compose & prelaunch_script

These two should have their own hashes, not just be buried in the final compose hash. Makes debugging way easier - you can tell exactly which part changed when hashes don't match. Plus they're raw strings (YAML/bash), so they don't go through JCS anyway. Keeping them separate gives better traceability.

[h4x3rotab]

Maintainer triage update: this remains open intentionally and is listed separately from vulnerability reports in the security roadmap/hardening table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#related-security-roadmap-and-hardening

Disposition: measurement roadmap. A future canonical hash scheme may still be useful. Current raw-byte hashing is intentional and is recorded in #550.