Consider shipping ship zlib dll, and/or removing zlib internal sources

Consider whether we should

• ship zlib as a separate dll, instead of linking it into Qt6Core
• remove qtbase/src/3rdparty/zlib, and rely on external sources

Advantages:

• zlib update (e.g. due to security issues found) won't require an update of qt sources & rebuild anymore
• Projects can make use of external zlib dll capabilities

Disadvantages:

• Windows does not provide zlib by default
  • Users who build Qt on Windows would have to install & build zlib themselves, or get pre-built packages from somewhere. Would we provide these prebuilt packages?
  • Every script packaging a qt app would need to be extended to also handle zlib1.dll
  • dll hell? How compatible are different zlib1.dll's in the path?
  • Is there a canonical zlib1.dll (which https://zlib.net/DLL_FAQ.txt suggests, but is not found on zlib.net)?
    Update: yes, there is. Under "Related External Links" are two download links. Search for "zlib for Windows 9x/NT".

On macOS, our packages use the dynamic zlib that's available on the system:

$ otool -L ~/Qt/6.5.0/macos/lib/QtGui.framework/QtGui 
/Volumes/Data/Users/egon/Qt/6.5.0/macos/lib/QtGui.framework/QtGui:
        @rpath/QtGui.framework/Versions/A/QtGui (compatibility version 6.0.0, current version 6.5.0)
        ...
        /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
        ...

Same on Linux:

$ ldd ~/Qt/6.5.0/gcc_64/lib/libQt6Gui.so
        ...
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa1de098000)
        ....