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
+23362048 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.8 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 4071190 and a987165 reduces the binary size increase from 5.6 MiB to 3.8 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 ↩

[lovell]

I'm still undecided about this. Chrome and Firefox are considering adopting the Rust-based jxl-rs decoder but it's not ready yet. Maybe we should align with that?

[kleisauke]

Aligning with major browser vendors seems sensible. This will likely miss the 8.18 release, so let's revisit it for 8.19.