This PR can fix:

5 warnings found (use docker --debug to expand):
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 23)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 24)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 25)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 26)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
"ENV key value" format (line 27)

Hi! I added `WASI_ARCH=arm64` command for the arm64 package version to
the installation command’s comment. I thought this would make the
command more clear.

With Ubuntu arm Github runners now available for general availability
(see Github blogpost here
https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/
) there is no longer a need to use the Ubuntu x86 runner and cross
compile in the ci. This means you no longer need to skip building the
sysroot on the ci for this platform.

* Pin CI runner images to explicit versions

CI is run infrequently enough on this repository that there's a
nontrivial chance that GitHub updates the definition of `ubuntu-latest`
for example between two CI runs. This can be confusing for contributors
as PRs seemingly break CI when in reality they have nothing to do with
the breakage and it's due to the image changing.

This PR pins all images to the definition of `*-latest` at this time.
The one exception is that one builder was pinned to 22.04 and I'm going
to update it to 24.04 here and see if I can't fix CI issues that come up.

This'll require explicit PRs to update these images in the future, but
hopefully that's only once every few ~years so not too much of a burden.

* Try not custom-installing clang 18

* Try to fix CI issue

* Fix CI again (attempt)

* Further try to fix CI

* Another fix for CI

Surely if I keep making commits that say "another fix" eventually I'll
run out of fixes. Surely, right? I'd put this in limerick form to be
more amusing if someone comes to read this but I'm not clever enough to
do that, so instead I'll just abruptly

* Update wasm-component-ld

Pulls in a fix for bytecodealliance/wasmtime#10058 in the adapters that
are used by default.

* Update wasmtime installed in CI

* Downgrade the build-only-sysroot check step

Looks like this is failing on Ubuntu 24.04, the new default of
`ubuntu-latest`, so downgrade it to have it get fixed in a separate PR.

* Try downgrading Wasmtime version again

* Update base Linux images to Ubuntu 20.04

* Update Wasmtime back to 29

Upstream want to deprecate `DEFAULT_SYSROOT`[^1][^2][^3], but one
blocker is wasi-sdk's usage of it.

Let's try to help that along by switching to using config files[^4]
instead.

This should result in no user-facing changes in functionality. (If it
does, then that's an LLVM bug that should be fixed there.)

[^1]: https://reviews.llvm.org/D158218
[^2]: https://github.com/llvm/llvm-project/issues/94284
[^3]: https://github.com/llvm/llvm-project/pull/77537
[^4]: https://clang.llvm.org/docs/UsersManual.html#configuration-files

Update to LLVM 19.1.5, and wasi-libc 574b88da. This notably picks up:
 - [WebAssembly] Fix rethrow's index calculation (llvm/llvm-project#114693)
 - [WebAssembly] Fix feature coalescing (llvm/llvm-project#110647)

* Update to the latest wasi-libc.

This contains two significant changes:
 - Implement a stub pthreads library for `THREAD_MODEL=single` (#518)
 - Initial FTS support (#522)

* Update to the latest wasi-libc with build fix

This update includes a build fix for shared library builds.

---------

Co-authored-by: Dan Gohman <dev@sunfishcode.online>

Pulling in a fix for bytecodealliance/wasm-tools#1850.

Pulling in some bug fixes and minor updates for the tool.

* llvmorg-19.1.0-rc3

* document setjmp/longjmp support

* README.md: mention SetjmpLongjmp.md

* bump wasi-libc

For following changes:

* https://github.com/WebAssembly/wasi-libc/pull/526
* https://github.com/WebAssembly/wasi-libc/pull/529

* bump llvm to llvmorg-19.1.0-rc4

* bump llvm to llvmorg-19.1.0

* Add missing architecture URL part to the installation script

* Remove unnecessary `export`s from installation instructions

* Fix missing $ sign in export

* Add `WASI_OS` as new parameter to use & install scripts in README

---------

Co-authored-by: Andrew Brown <andrew.brown@intel.com>

Keeping it up-to-date with its release cadence.

There is an option to compile debug information to separate file. It's supported in Clang via -gsplit-dwarf to generate dwo files but we need llvm-dwp tool to combine them into single dwp file supported by Chrome DWARF extension https://developer.chrome.com/blog/faster-wasm-debugging

These aren't needed anyway and fix a build issue discovered in #474.
Additionally a typo was fixed here too.

* Add back `VERSION` file to release tarballs

Make sure it makes its way into the sysroot tarball and then copy it
from the sysroot location to the top of the sdk tarball as well.

Closes #471

* Fix how `VERSION` is installed

This pulls in an update to how WIT files are processed notably around
nested package forms in the text format.