ZLib VS wordle-trie-packing

A fix has been checked into the upstream git repo: https://github.com/madler/zlib/pull/843 but a release has not yet been made including it.

So the real issue here is that the lack of tree validation before the tree construction, I believe. I'm surprised that this check was not yet implemented (I actually checked libwebp to make sure that I was missing one). Given this blind spot, an automated test based on the domain knowledge is likely useless to catch this bug.

[1] https://github.com/madler/zlib/blob/master/examples/enough.c

In the source code of the Node.js opensource project, lib folder contains JavaScript code, mostly wrappers over C++ and function definitions. On the contrary, src folder contains C++ implementations of the functions, which pulls dependencies from the V8 project, the libuv project, the zlib project, the llhttp project, and many more - which are all placed at the deps folder.

Seeing the text in red got me thinking for a moment, "wow, didn't realize pirates had such love for an open-source compression library"

cd "${srcdir}/zlib-$pkgver/contrib/minizip" make install DESTDIR="${pkgdir}" install -D -m644 "${srcdir}/zlib-$pkgver/LICENSE" "${pkgdir}/usr/share/licenses/minizip/LICENSE" # https://github.com/madler/zlib/pull/229 rm "${pkgdir}/usr/include/minizip/crypt.h"

```

Doing this, and then doing the variable length encoding I got the file down to 13,181 bytes (it was 13,180 bytes, but I needed to add a 7 bit termination string so that you can properly decode the file after you write it to disk, otherwise when the file rounds to the nearest byte you have random 0s that get decoded).

I'm sure with some twiddling of the alphabets some more you could save a few more bytes, but this does better than both Brotli on a ASCII trie and the Huffman Trie by almost 1KB (https://github.com/adamcw/wordle-trie-packing#all-words), so I'm very happy.