Use patched version of zlib-ng to fix install name

[freakboy3742]

Fixes #8671. Alternative to #8672 and #8673

When zlib-ng is compiled on macOS, it sets the install name of the libz.1.dylib to @rpath/libz.1.dylib. This means that any subsequent load requires a valid DYLD_LIBRARY_PATH to resolve the link.

Recent versions of macOS have a feature called System Integrity Protection (SIP) which (amongst other things) prevents DYLD_LIBRARY_PATH from being passed into subshells. As the build's dependencies aren't on the default library path on macOS, delocate-wheel is unable to resolve the libz library.

SIP is disabled on GitHub Actions configurations, so this problem isn't seen in CI; but is enabled by default on macOS machines, so individual developers building Pillow dependencies will get an error from cibuildwheel when the wheel is repaired.

This PR uses the PATCH_DIR mechanism provided by multibuild to provide a patch for zlib-ng (authored by @radarhere, submitted upstream as zlib-ng/zlib-ng#1867) to fix the issue with zlib-ng's install dir during the original build.

This is an alternative to:

• Correctly pass DYLD_LIBRARY_PATH to delocate #8672, which achieves the same end by setting DYLD_LIBRARY_PATH so delocate-wheel is able to resolve @rpath; and
• Rewrite the install_name of the ZLIB-NG library on macOS #8673, which uses an explicit call to install_name_tool to fix the dylib after it is compiled.

I'd argue this is the best of the three approaches, as it fixes the root problem at the source, in a way that will (eventually) require no patch at all.

[radarhere]

You may or may not have realised that the Windows build has seven "patches" of its own (they're not true patches at the moment, but rather find and replace) - https://github.com/python-pillow/Pillow/blob/main/winbuild/build_prepare.py#L139

Do you think these should be moved to be part of a "patches" directory as well?

[freakboy3742]

I wasn't aware of the Windows patching strategy - I haven't really spent any time looking into the Windows build, since there's no overlap with iOS or macOS.

I agree it looks like those patches would be at least a candidate for migrating to a common patches folder - but I'd suggest such a refactor is orthogonal to this change. The macOS and Linux wheel builds are almost completely independent to the Windows builds at present; I don't know if there's much to functionally be gained by merging in this way.