zlib-ng strategy -- drop in for zlib vs side by side installation

### Your question:

We've been discussing https://github.com/conda-forge/zlib-ng-feedstock/issues/10#issuecomment-3452213570 making zlib-ng a potential drop-in for zlib.

@jaimergp mentionned

> Some other references for similar conversations in other distros:
>
> - [ArchLinux](https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/UPJYWKUJRQDHNU4IXGFDU6GVEHPSTKDZ/#UPJYWKUJRQDHNU4IXGFDU6GVEHPSTKDZ): done
> - https://github.com/bottlerocket-os/bottlerocket-core-kit/issues/392: done
> - https://github.com/amazonlinux/amazon-linux-2023/issues/872: in discussion
. - [Debian](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002056): in discussion
>
> OpenSuSE [seems](https://opensuse.pkgs.org/tumbleweed/opensuse-oss-aarch64/libz-ng-compat1-2.2.5-1.1.aarch64.rpm.html) to be using it too? (I had to click on "Required by"). https://github.com/dotnet/runtime/issues/101465

personally, I think that each individual package should opt-in to using zlib-ng instead of changing zlib as a whole.

However, there seems to be a strong push by many that this might be the wrong strategy given the little maintenance that the zlib library has seen in recent years

edit: Personally, i'm scarred from the [jpeg-turbo swap which took 6 years](https://github.com/conda-forge/conda-forge.github.io/issues/673) and was an all-or-nothing. I much prefer the slow, gradual, and intentional approach.

cc: @mgorny @brainstorm @morotti