Make macOS bindist configure more deterministic

[mboes]

GHC from a bindist requires running ./configure and then make install. One would assume that the result is always the same, in
particular if we run this twice on the same host with the same
environment variables. However, this is not the case. See #1461.

The fix is to set an environment variable telling ar and friends to
not futz around with timestamps in static library archives. This
environment variable is only necessary and only has an effect on
macOS, but there's no harm in setting it always. If the bindists stop
having a configure stage, or start using libtool instead of ar and
ranlib, then the fix will better be pushed within the bindists
themselves, using the -D flag to libtool, introduced in XCode
10.2.

Fixes #1461.

[mboes]

With this change, on GitHub Actions the build goes down from 36 minutes to less than 13 minutes. With a 99.9% cache hit rate on BuildBuddy.

[aherrmann]

Great, thanks for tracking this down!

[aherrmann]

This makes me think that we should also be passing D to ar in the static link actions.

[mboes]

If we used libtool instead of ar on macOS, then that would be possible. But I believe ar does not support the -D flag. In fact Bazel sometimes picks libtool over ar, which is deprecated on macOS. But we override that here. Perhaps migrating to libtool completely is what we should be aiming for. Or better yet, maybe it's possible now to leverage the CC toolchain API to give us a linking action that works, without us having to hardcode either ar or libtool.

[aherrmann]

@mboes Good point about the CC Starlark API. I've opened #1469 to track this.