Use rustc's Apple deployment target defaults when available

[BlackHoleFox]

To follow on rust-lang/rust#105354 being released in 1.71, and soon rust-lang/rust#104385, the changeset here aims to make Apple deployment targets more consistent and support future minimum bumps better. To do so, the root change is to try asking rustc for what it thinks the default deployment target version is before using a hardcoded one after cc checks the environment directly for an overridden version. For any users who aren't on 1.71+, everything will work exactly the same.

While in the area, duplication of checking the iOS and watchOS default deployment target elsewhere in the library was removed and a bad watchOS version (2.0 -> 5.0) was corrected.

Also, this branch forks from #708 and has a rebased version of its one commit. If only GitHub supported stacked PRs... Due to that though, its better to review this per commit.

[thomcc]

Hm... should we emit rerun-if-changed flags for these env vars in any situation? (Perhaps it would be needed in complex situations with cross-compiling?)

[BlackHoleFox]

Originally I opted to avoid that (a prior revision of the branch actually ran it through the caching env paths) for consistency reasons. Only cc would rerun, so an arbitrary number of objects not created by cc in the build tree would have a different deployment target and that seems worse then doing nothing and making people run cargo clean to switch.

I think that if this is desired behavior, rustc or cargo should handle it instead and invalidate the entire build tree at once.

[youknowone]

This is a really good idea.

[nox]

Prior to this change, the cc crate just didn't emit any -mmacosx-version-min flag on its own, right? That's a breaking change on its own, and I don't think #901 changes that.