bug#67022: Gzip decompression can be 60% faster using zlib's CRC32

[wrotycz]

> current code in zlib for CRC-32 does not use slice-by-8. It uses braids, 
which is faster.    It turns out not to be that fancy in gzip's harness.  
It seems to be tiny bit faster than slice-by-8 during decompression but slower 
during compression; to the point of being on par with current Sarwate 
algorithm, or tiny bit faster (  paste.ee paste.ee/p/QeBKL  ).    Benefits are 
not that unambiguous. Though I didn't make that slicing-by-8 (  paste.ee 
paste.ee/d/mkqTU/0  ) work with gzip properly, I would consider it in a context 
of application itself. If braids are faster with decompression, not much 
though, and slower with compression, then it would make sense to weight it 
somehow in this context and asses fitness for this particular application.    
Either way, whichever algorithm would be chosen it still would make sense to 
generate crc table dynamically, when program starts. It takes, on my turtle 
computer, less than 10 us. Even rolled version. Unrolled isn't much faster 
either (10%-20%).  Using already generated 'Sarwate's' table  as a 
basis, halves that time.  That's imperceptible differences. None is going 
to notice that, even with atomic clock.