Encode WebP via WASM

[bep]

See https://github.com/gen2brain/webp

Now, if we then somehow could get rid of libsass we will have a CGO free build (no need for extended), which would be a massive win. We would want to continue producing theextended archives, of course, to make sure we 1. Avoid breaking builds in the wild (e.g. Netlify) and 2. In case we need to re-introduce it in the future.

[gen2brain]

Just a few notes. Currently, there is no way to initialize a Wazero runtime, it will do it lazy if it is not initialized. The Wazero docs clearly state that panic can happen when concurrently initializing the same runtime, and my usage is such that I don't want to do that unconditionally in init() (i.e. I use it for the image.Decode and without concurrent code).
There is sync.OnceFunc is in the code but it is not enough. I have never seen it for Webp because it works really fast, but for other libraries I have (avif, jpegxl, etc.) that is the case. I will add Initialize() when I find time so the user can do it manually.

The other issue is that library will first try to use a dynamic/shared library (if found) via purego. Due to the way purego works (at least on Linux), the binary will always link to libc, even with CGO_ENABLED=0, so there are again issues if you compile on e.g. recent glibc and try to use it on some older system. You can disable purego with the nodynamic build tag, then only WASM will be used.

[cmahnke]

That's a great idea, since it would also allow (in the long run, since there certainly still be need sort some sort of wrapper / mapper) for more image formats available via WASM, like libultrahdr-wasm for #12781

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[medyagh]

this might fix #14103

currently Kubernetes netlify sites can not be updated to latest hugo because of this

[bep]

currently Kubernetes netlify sites can not be updated to latest hugo because of this

@medyagh Hugo builds its own documentation on Netlify with the latest and shiniest Hugo version, but you need to upgrade to the newer build image on Netlify (the old one is also deprecated):