* Add a CI check for testing toolchains as-distributed

One aspect of testing lost in the CMake-based migration is the ability
to test the toolchains as distributed in release artifacts. Tests use
`--sysroot` and `-resource-dir` (soon) to customize how the host
compiler runs but this means that it would be possible to regress the
default sysroot theoretically. To rectify this situation this commit
adds a new CI test which uses the release artifacts of previous steps to
build a `wasi-sdk-*.tar.gz` tarball which is then extracted and tested
as-is. A new flag was added to the cmake configuration to avoid
depending on fresh sysroot libraries for tests and instead test the host
toolchain.

* Fix version.py script running

* Fix artifact download

* Add ninja

* Update submodules in new test job

* Only add extra options for libcxx build

Otherwise the test directory seems like it inherits these options which
isn't desired when testing the host toolchain.

* Refactor handling env vars in CI build

This commit updates the handling of various environment variables to
centralize them in one location in `main.yml` as part of CI
configuration. This removes a few custom-named variables in favor of
using explicitly-listed env vars. Additionally this moves some env var
management from the CI container files to the github actions config as
well to keep everything in one place ideally.

* Add some more comments about where configuration comes in

I noticed in a [recent build] that the cache size for Windows is quite
large at 500M. That might be related to switching to MSVC, I'm not sure,
but something else I've realized is that as-configured wasi-sdk will
continuously grow the cache over time and it won't ever get trimmed
until we hit github actions limits. This is because the cache is
restored from an older version, then appended to with the current
build, then saved again. That theoretically means that each builder
could make up to a 5G cache which is a bit too large.

This commit adds an extra step that removes all objects older than 1d to
ensure that older builds eventually get cleaned out of the cache. GitHub
Actions should then still delete older caches pretty regularly but each
individual cache should be bounded still.

[recent build]: https://github.com/WebAssembly/wasi-sdk/actions/runs/10045872592/job/27764084758?pr=456

This command is generally not included in toolchain files. It is used in
project configuration files that will consume the toolchain file. Also,
such a low value triggers warnings, support for <3.5.0 is being removed
from CMake.

* Use MSVC for the Windows toolchain instead of MinGW

Explicitly use MSVC to avoid the runtime dependencies that the default
toolchain CMake is using is bringing in.

Closes #454

* Update .github/workflows/main.yml

Co-authored-by: Andrew Brown <[email protected]>

* Specify MinSizeRel in `build.sh`

Looks like MSVC defaults to "Debug" instead of an empty string to so the
default logic which works for other compilers isn't kicking in here.

* Don't persist ccache stats across runs

* Move zeroing

---------

Co-authored-by: Andrew Brown <[email protected]>

* Retire clang_version

Note: this makes the "install" target install the compiler rt
into the compiler's runtime directory.  IMO, it's what "install" is
supposed to do.  If you want to avoid modifing the runtime directory
for some reasons, you can still do "dist" without "install".

* wasi-sdk-sysroot.cmake: Avoid modifying things out of CMAKE_INSTALL_PREFIX

* wasi-sdk-sysroot.cmake: control the resource-dir modification by a cmake option

* Add LTO build of wasi-libc

* Add LTO build of libc++

* Update wasi-libc (to include the LTO support)

* Add a comment about /llvm-lto/${llvm_version} convention

* Use separate targets for wasi-libc with and without lto

A downside: this makes four more copies of wasi-libc source tree.

* Make LTO build optional

To include WebAssembly/wasi-libc#517,
which is necessary to avoid modifying host compiler's resource
directory.

At least on my environment (macOS if it matters), without the above
mentioned fix, gmake tries to create the directory for wasi compiler-rt
during wasi-libc build. I'm not sure why it didn't happen for others.
cf. #445

This is an attempt to fix CI errors where the `config` submodule is now
located on a commit further than 32 commits behind the main branch
(presumably).

This commit fixes a bug from the cmake migration where tests were not
actually testing the correct target. Object files were compiled with the
right options but the link step was missing both `--target` and
`-pthread` which caused everything to accidentally be tested as
`wasm32-wasi`. When fixing this one test was needed to have its stderr
updated because the component output of `wasm32-wasip2` is slightly
different. A timeout was additionally added because without `-pthread`
at the link step some tests infinitely ran which made debugging
difficult.

* Require that the compiler is Clang, for example gcc and msvc cannot
  compile to WebAssembly.
* Require that the Clang version is above the minimum threshold. Unsure
  what the minimum threshold is at this time so I've set it to 18.0.0

Like we have for other targets, this adds a `.cmake` file for the new
name of the old `wasm32-wasi` target, now called `wasm32-wasip1` in
`wasi-libc`.

This commit fixes running the test suite on Windows for CI at least by
fixing up a few minor edge cases to ensure that everything runs
consistently.

This commit adds a test and matrix entry to CI which asserts that the
sysroot can be built to run tests using a stock Clang compiler found on
the system. This fixes a few minor issues as well in developing this.

This additionally refactors CI a bit to move shared steps amongst jobs
into separate composite actions in this repository to avoid duplication
across jobs.

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