[web] End-to-end content-hashing for deferred loading parts across Dart SDK, Engine, and Tools #191917

Summary

Part of umbrella issue #149031.

Extend content-hashing support to multi-module deferred loading applications (loadLibrary(), *.part.js, _module*.wasm) across the Dart SDK compilers, Flutter Engine, and flutter_tools.

Scope & Multi-Subsystem Alignment

1. Dart SDK (dart2js):
   • Add --content-hash-deferred-parts flag.
   • Hash part fragments upon emission and populate DEFERRED_PART_URIS in the main bundle loading state before emitting main.dart.js (resolving circular dependency).
   • Sync hashed filenames with DumpInfoData.outputUnitFilenames.
2. Dart SDK (dart2wasm):
   • Require --use-load-ids for release builds with deferred libraries so WebAssembly bytecode uses integer module IDs rather than hardcoded string paths.
   • Perform WASM deferred module hashing (main.dart_module<id>.<hash>.wasm) and --deferred-map JSON rewriting post-compilation in flutter_tools.
3. Flutter Engine (flutter.js):
   • Add deferredLibraryManifest?: Record<string, string> support to WasmApplicationBuild in the flutter.js web loader.
   • Update defaultLoadDeferredModules in entrypoint_loader.js to dynamically resolve module IDs to hashed URLs.
4. flutter_tools:
   • Pass deferred content hashing flags to compilers when --web-content-hash is specified, removing the deferred loading prohibition from Phase 1.