Update zlib-ng library to 2.2.2

[EliahKagan]

This updates the zlib-ng submodule from the 2.2.1 tag to the 2.2.2 tag, since the patch release 2.2.2 came out several days ago.

I had originally looked into this in the hope that it would help with #200, but as described in #200 (comment) it looks like it does not help with that at least on some systems including the RISC-V test system I am using, even though it includes a change that tries to do so. Nonetheless, it seems to me that it may be valuable to bump the submodule to this new stable bugfix/patch release, in view of its several improvements.

The submodule version was last increased here in 33dff11 (#211). Unlike that change, this one is just a patch release, and as far as I can tell from building it locally, it looks like just bumping the submodule commit ID, without having to modify any build scripts or other files, may be sufficient here.

If this PR is merged, that does not necessarily require an immediate new release of this project's crates. I'm not sure if it's best to do that as well now or to wait.

[Byron]

Thanks a lot for taking us in the right direction.

One can hope that after the interaction with the upstream zlib-ng project, the RISCV issue can be fully resolved.

As it still reproducibly crashes when trying it with gix, and there seem to be no substantial or requested changes in zlib-ng, it seems fair not to create a new release of this crate at this time.

[EliahKagan]

One can hope that after the interaction with the upstream zlib-ng project, the RISCV issue can be fully resolved.

Yes. I wanted to test with the upstream test suite before posting there, but I have done so and posted zlib-ng/zlib-ng#1705 (comment).

As it still reproducibly crashes when trying it with gix, and there seem to be no substantial or requested changes in zlib-ng, it seems fair not to create a new release of this crate at this time.

Yes, actually there are more upstream test failures on my test system with 2.2.2 than 2.2.1 (all failures with both versions are due to RVV being used and go away when -DWITH_RVV=OFF is passed when configuring with cmake). I was unaware of that at the time I opened this pull request, which is why I didn't mention it here.

I am unsure if this really translates into more practical situations where a problem would arise. My guess is that such scenarios are uncommon, and thus that 2.2.2 is still overall better than 2.2.1 (mainly due to having zlib-ng/zlib-ng#1773). So if people report they need the other fixes present in 2.2.2, then I think it could be okay to do a release here, even without further progress on RVV detection. Otherwise I very much agree it's better to put it off.

[EliahKagan]

Since the goal of #218 remains relevant in 2.2.2, I've rebased that and adjusted it in a way that moves it as close as I think it can reasonably go, at this time, to what has been suggested. In some cases, it was necessary to choose between doing something more complicated than had been discussed, or something simpler. I resolved those cases by doing the simpler thing.