Enable embedded sdk builds

[daskruegge]

Description

• Embedded WASM SDK support: Add EmbeddedStubs C target with linker stubs for Unicode normalization symbols missing from the Embedded Swift WASM runtime but needed for string comparisons and interpolation, enabling builds with the embedded SDK variant.
• Instead of the above we use linkerSettings to include the swiftUnicodeDataTables library for string interpolation and comparison support via Equatable coformance. Without the unicode data tables, the linker throws an error. The included data tables increase the size of the resulting WASM by ~35kB uncompressed and ~21kB compressed.
• Makefile-based build system: Replace the pnpm script setup with a Makefile that auto-derives SWIFT_SDK from .swift-version and a new .swan-config config file. Supports SWIFT_MODE=embedded to append -embedded to the SDK, DEBUG=0/1 for release/debug builds, and SWIFT_SDK override. Includes sdk-install target to download and install the WASM SDK with checksum verification.
• Centralized SDK version management: Upgraded .wasm-sdk-version to .swan-config as a single source of truth for WASM SDK versions across Makefile and CI. The file uses a shell/make-compatible KEY=VALUE format with keys matching the toolchain prefix from .swift-version.
• Adds a new GitHub Actions workflow: (swift-wasm-embedded.yaml) that verifies the WebGPU and BitonicSort WASM targets compile successfully in embedded mode. Toolchain and sdk versions for CI and embedded mode are read from .swan-config file

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[bmedina]

Is this file intended to be included in this PR?

[bmedina]

GitHub makes the diff hard to read. Is this:

• JavaScriptKit update
• Formatting changes?

We should get formatting enforced on each PR....