Deployment target improvements

[drewcrawford]

Issues like #64 are often motivated by some underlying issue with deployment targets (targets too old require backdeployment shims, and then the question arises how do we package the shims, it's a tough problem since cargo build doesn't build applications).

Less obviously the docs are wrong about how to set deployment targets which motivates a subset of those issues. Broadly the documentation covers

• Package.swift which controls which platforms the package could be built for
• SwiftLinker::new which controls which platforms the package is being built for

...but then we go on to link the package into a Rust program, which probably has a DT of macOS 11, see:

rustc --print=deployment-target
deployment_target=11.0

This mismatch will cause various compatibility shims to be expected to support macOS 11 and when they aren't in the right locations the program will crash at runtime.

I'm not entirely sure what to do about this, some options are:

1. If SwiftLinker added println!("cargo:rustc-env=MACOSX_DEPLOYMENT_TARGET={version}"); that changes the Rust DT to the expected value and this works in simple cases. However I'm a bit skeptical of this solution, what if two libraries disagree about DT? The ultimate program can only be built for one.
2. Instead of doing this for you, docs could tell you to do it in your own build.rs. While this makes it a little more visible, I'm still not certain there's a good way to handle conflicts between packages on this.
3. Another idea is to have SwiftLinker use Rust's DT as probed at runtime (instead of trying to it as an argument to the constructor). Then everything will build with the same DT (probably macOS 11). That's not the most practical default but it is Rust's, and then affected users can use the build.rs workaround but ideally at the binary level rather than the library level.

[drewcrawford]

Further testing suggests that

println!("cargo:rustc-env=MACOSX_DEPLOYMENT_TARGET=15")

within a library crate's build.rs has no effect on binary crates depending on it, and can cause issues when binaries are run due to missing dylib shims, etc.

From the perspective of avoiding conflicts over deployment targets among various dependent crates, this makes sense. But from the perspective of following the documentation and trying to configure a deployment target it is more problematic.

I see no obvious way around removing SwiftLinker::new in favor of an API automatically detecting the actual Rust-side deployment target and using that. And advising downstream crates to adjust via environment variable.