(Optionally) Pass `-headerpad_max_install_names` when building stage3 `zig` on macOS

[carlocab]

Zig Version

0.10.0

Steps to Reproduce and Observed Behavior

1. Build a dynamically-linked zig on macOS. This dynamic linkage can be to libLLVM, or any library that LLVM depends on (e.g. zlib, libzstd, etc).
2. Change the install name of a library dependency to a longer path. (e.g. install_name_tool -change /path/to/old/libz.1.dylib /longer/potentially/fictional/path/to/some/other/libz.1.dylib /path/to/zig).

brew does the equivalent of the above when building a binary package of Zig with brew bottle, which produces the following error:

  ==> Determining zig bottle rebuild...
  ==> Bottling zig--0.10.0.arm64_monterey.bottle.tar.gz...
  Error: Failed changing install name in /opt/homebrew/Cellar/zig/0.10.0/bin/zig
    from /opt/homebrew/opt/zstd/lib/libzstd.1.dylib
      to @@HOMEBREW_PREFIX@@/opt/zstd/lib/libzstd.1.dylib
  Error: Updated load commands do not fit in the header of /opt/homebrew/Cellar/zig/0.10.0/bin/zig. /opt/homebrew/Cellar/zig/0.10.0/bin/zig needs to be relinked, possibly with -headerpad or -headerpad_max_install_names

This is needed in order to support installation into prefixes that are different from the one used when building in Homebrew CI.

Expected Behavior

No errors. This can be done by passing -headerpad_max_install_names when linking Zig. I can patch build.zig to do this by setting exe.headerpad_max_install_names = true, but it would be nice to not have to.

Moreover, cmake passes -headerpad_max_install_names when linking by default, so I'd argue that it's needlessly surprising for users to have Zig built with cmake behave differently.

[carlocab]

For context, this appears to be needed for https://github.com/Homebrew/homebrew-core/pull/114382, which updates the version of Zig that Homebrew ships.

[carlocab]

I have too many GitHub notifications, so I didn't realise that this was fixed. Thanks @mikdusan!