vendor zlib instead of relying on system version

[weissi]

Motivation:

Relying on the system zlib causes issues if that library (or its headers) doesn't ship with the system.

Modifications:

Vendor it.

Result:

• Fewer dependencies.
• Binary size increase negligible. The sum of the debug builds of all .o files is less than 200kB. A linked release build will make this even smaller:

$ du -k .build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/*.o
12	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/adler32.c.o
12	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/crc32.c.o
60	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/deflate.c.o
16	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/inffast.c.o
40	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/inflate.c.o
16	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/inftrees.c.o
40	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/trees.c.o
8	.build/arm64-apple-macosx/debug/CNIOExtrasZlib.build/zutil.c.o

[Cyberbeni]

zlib depends on the address of the z_stream struct being unchanged between calls, so storing it directly is error prone. And although it might currently be working as expected, it relies on undefined behavior, see: https://github.com/swiftlang/swift/blob/af3e7e765549c0397288e60983c96d81639287ed/stdlib/public/core/UnsafePointer.swift#L197-L205

had a similar issue here: adam-fowler/compress-nio#12