Add optional XCFramework distribution tooling

[Anywhere-Music-Player]

Summary

Adds an isolated, opt-in build path for producing:

• AudioKitEX.xcframework
• CAudioKitEX.xcframework

The generated frameworks support iOS devices, iOS Simulator, and native macOS. Swift Package Manager remains the default integration path, and this change does not add or publish prebuilt binaries.

Motivation

Binary packaging for AudioKitEX must coordinate the Swift AudioKitEX module, the C and C++ CAudioKitEX module, and a compatible AudioKit binary.

An archive can succeed while still containing missing public headers or symbols, incompatible deployment targets or architectures, unstable module metadata, mismatched dSYMs, or linkage failures that only appear in a consumer. Without a shared recipe, every downstream binary user must independently maintain and validate this integration.

Dependency contract

AudioKit is consumed as an explicit external XCFramework input instead of being copied into or bundled with the AudioKitEX output.

Before archiving, the builder validates:

• The required AudioKit release
• Deployment-target compatibility
• Selected macOS architectures
• Binary checksums

This keeps the AudioKit and AudioKitEX repositories and artifacts independent.

Included tooling

• Framework targets for the existing Sources/AudioKitEX and Sources/CAudioKitEX trees
• Public CAudioKitEX header packaging
• A command-line builder and Finder-friendly build.command wrapper
• Configurable deployment targets
• Optional Intel Mac support
• Stable Swift interfaces and matching dSYMs
• Exported-symbol checks and build provenance
• Atomic replacement of both XCFrameworks

Safety and validation

The builder:

• Requires a clean checkout based on an AudioKitEX release tag
• Validates architectures, deployment targets, dynamic linkage, exported C symbols, module interfaces, headers, and dSYM UUIDs
• Verifies linkage between AudioKitEX, CAudioKitEX, and AudioKit
• Runs a clean binary-only smoke consumer that imports AudioKit and AudioKitEX and creates a DryWetMixer for iOS Simulator and every selected macOS architecture

Project impact

• No changes to AudioKitEX production sources or public Swift API
• No changes to Package.swift behavior
• No changes to the existing SwiftPM workflow or default CI path
• All tooling is isolated under XCFramework and is fully opt-in
• Binary hosting and release policy remain downstream decisions

This is the companion build path to the AudioKit XCFramework tooling while keeping both distributions independent.