Move libjxl and brotli to 'web' group dependencies

[kleisauke]

Given that JPEG XL support has now shipped in Safari¹ and is under consideration in both Firefox² and Chromium³, I think it's time we move libjxl and brotli to the 'web' dependency group.

From a security standpoint, this should be acceptable. The fuzzers have uncovered only a few non-critical integer overflows related to saving float32 pixels, all of which have been reported upstream (and VIPS_BLOCK_UNTRUSTED will block JXL load/save anyway).

Resolves: #40.

Size diff of resultant libvips-42.dll file in the statically-linked x64 variant:

@@ -1,4 +1,4 @@
 $ ls -l bin/*.dll | awk '{print $5,$9}'
-19362816 bin/libvips-42.dll
+23463936 bin/libvips-42.dll
 489984 bin/libvips-cpp-42.dll
 

Marked this PR as draft due to these TODO items:

• Commit libvips/libvips@9652214 was only landed ~2 weeks ago, perhaps we need more fuzzing time?
• This builds against libjxl its main branch (to avoid missing more than a year of upstream improvements), perhaps we should wait for version 0.12.0? See: 🚀 Release v0.12.0 📦  libjxl/libjxl#4376.
• Is a binary increase of 3.9 MiB acceptable? For comparison, wasm-vips's vips-jxl.wasm dynamic module is only 2.3 MiB. We might be able to reduce binary size by disabling some Highway targets (e.g. -DJPEGXL_ENABLE_HWY_AVX3_DL=OFF, -DJPEGXL_ENABLE_HWY_SSE2=OFF, etc.). Edit: Commit e4611be reduces the binary size increase from 5.6 MiB to 3.9 MiB.

Footnotes

1. https://webkit.org/blog/14445/webkit-features-in-safari-17-0/#:~:text=Images%20and%20video-,JPEG%20XL ↩

2. https://github.com/mozilla/standards-positions/pull/1064 ↩

3. https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/NmOyvMCCBAAJ ↩