Get apple sdk root from cc instead of xcrun

[jparismorgan]

What

As part of Tauri building via Bazel, this PR fixes a hermeticity bug coming from swift-rs.

Specifically, swift-rs previously used the host machine's xcrun to fetch the Apple SDKs and deployment targets for iOS and OSX. The issue is that xcrun is a host-machine binary which points cc-rs at non-hermetic XCode SDKs. This results in non-hermetic builds locally (when XCode and XCode CLI Tools have been downloaded) and failing builds on CI (when they are not present). The error you get on CI is:

18:01:16 cargo:rustc-check-cfg=cfg(custom_protocol)
18:01:16 cargo:rustc-check-cfg=cfg(dev)
18:01:16 cargo:rustc-cfg=dev
18:01:16 cargo:dev=true
18:01:16 cargo:rustc-check-cfg=cfg(desktop)
18:01:16 cargo:rustc-check-cfg=cfg(mobile)
18:01:16 cargo:rustc-cfg=mobile
18:01:16 cargo:rustc-link-search=native=/Library/Developer/CommandLineTools/usr/lib/swift/iphoneos
18:01:16 cargo:rustc-link-search=native=/usr/lib/swift
18:01:16 cargo:rustc-link-lib=clang_rt.ios
18:01:16 cargo:rustc-link-search=/Library/Developer/CommandLineTools/usr/lib/clang/17/lib/darwin
18:01:16 
18:01:16 --stderr:
18:01:16 thread 'main' panicked at external/tauri-deps__swift-rs-1.0.7/src-rs/build.rs:280:17:
18:01:16 Failed to get SDK path with `xcrun --sdk iphoneos --show-sdk-path`
18:01:16 stack backtrace:
18:01:16    0:        0x104dfe440 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
18:01:16    1:        0x104e3fe44 - core::fmt::write::ha36a8060c13608ea
18:01:16    2:        0x104df2f50 - std::io::Write::write_fmt::h431832c8ebcc85c9
18:01:16    3:        0x104e00b08 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
18:01:16    4:        0x104e006b8 - std::panicking::default_hook::h4ebc6eb4ae179807
18:01:16    5:        0x104e01724 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
18:01:16    6:        0x104e01150 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
18:01:16    7:        0x104dfe904 - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
18:01:16    8:        0x104e00e18 - _rust_begin_unwind
18:01:16    9:        0x104e3c5ec - core::panicking::panic_fmt::h410d3f147658259b
18:01:16   10:        0x104b3fd8c - swift_rs::build::SwiftLinker::link::hd053f7526be199c3
18:01:16   11:        0x104820d24 - tauri_utils::build::link_apple_library::hac815aff63580ece
18:01:16   12:        0x104817954 - build_script_build::main::hb40b5b63f6ea92a9
18:01:16   13:        0x10481fec8 - std::sys::backtrace::__rust_begin_short_backtrace::he90ed75a0f0964f4
18:01:16   14:        0x10481eca0 - std::rt::lang_start::{{closure}}::h7d0e1907eef4e316
18:01:16   15:        0x104de5f90 - std::rt::lang_start_internal::h9e88109c8deb8787
18:01:16   16:        0x104819b3c - _main

Our solution here is to use cc to find the SDK path and deployment target. Feels like somewhat of a hack, but appears to work and the code is simple enough.

Testing

I can build and run Doty run with this plus the new rust_binary() target on my local machine. We'll still have to see if it gets CI to pass, but it's a step in the right direction.