Enhancement: add support for jpegli as jpeg encoder

Nobody has claimed this yet.

## Feature request

### What are you trying to achieve?

The JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere. - source: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front.

#### Why is it worth adding
Google did a visual study using jpegli, made public in 2024: https://github.com/google-research/google-research/tree/master/mucped23

> jpegli likely lifts jpeg to the WebP quality, and far above in high quality - https://twitter.com/jyzg/status/1758436289181859995

> There is no bait. Jpegli is a huge upside, 30–35 % more compression without decode slowdown, without compatibility nightmare. It just wörks. It continues on the trajectory of mozjpeg and guetzli but goes further in speed and density. - https://twitter.com/jyzg/status/1762239776667685361

> The second and third deficiencies are not a big issues at high quality (libjpeg q85+), but reduces Jpegli's ability to compete in the lowest quality class, like q75-.
Overall I believe jpegli is in its own class of jpeg codecs, combining the quality of guetzli while being faster than mozjpeg and allowing 10+ bits of dynamics for "8 bit" jpegs.
I believe Jpegli and jpeg xl lead in the highest quality category (5 BPP). In mid quality (1.5 BPP) jpeg xl and AVIF are the leaders, Jpegli likely better than WebP. In low quality (0.5 BPP) AVIF will be great for graphics and indoor photos while JPEG XL can still outperform AVIF in nature photos. In low quality WebP can be better than jpegli. - https://news.ycombinator.com/item?id=36429397

> Jpegli will lift traditional JPEG compression density by 25–30% and support 10+ bit HDR within the backward compatible 8 bit formalism. Jpegli is based on porting jpeg xl encoding strategies back to old jpeg. It is a whole new reimplementation, instead of tweaking old libs such as libjpeg, libjpeg-turbo or mozjpeg. Jpegli is API and ABI compatible with its usual alternatives like three mentioned before. - https://news.ycombinator.com/item?id=38644005

Further blog posts (from last year, could be that jpegli advanced by now):
- https://giannirosato.com/blog/post/jpegli/
- https://giannirosato.com/blog/post/image-comparison/
- From Google: https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

#### How to integrate

Jpegli is included in the JXL repo: https://github.com/libjxl/libjxl/blob/main/lib/jpegli/README.md:

> When building the parent libjxl project, two binaries, tools/cjpegli and tools/djpegli will be built, as well as a lib/jpegli/libjpeg.so.62.3.0 shared library that can be used as a drop-in replacement for the system library with the same name.

libvips discussion: https://github.com/libvips/libvips/discussions/3871

### When you searched for similar feature requests, what did you find that might be related?

https://github.com/lovell/sharp/issues/2731

### What would you expect the API to look like?

Probably an option like `[options.mozjpeg]` -> `[options.jpegli]`.

### What alternatives have you considered?

see above; jpegli is an alternative to mozjpeg, while being faster and achieving better quality.

Start with lib/jpegli/README.md in the libjxl repository, then compare sharp's existing options.mozjpeg integration and API entry points. Done means determining whether jpegli can be exposed as an options.jpegli encoder and identifying the compatibility and validation work needed for that integration.

Written by the indexing model from the issue text.