This commit allows -flto=thin to be added to the global CFLAGS, though
we don't enable it by default for the time being.

This patch enables certain wasm feature flags and optimizations that
we approve of.

https://github.com/WebAssembly/wasi-libc/pull/563#discussion_r1940291020

This PR updates ADAPTER_URL to reference the latest release version
(versions 29.0.1)

This PR updates WASM_TOOLS_URL to reference the latest released version
(version 1.224.0)

This PR updates WASMTIME_URL to reference the latest release version
(29.0.1)

This PR updates LIBRT_URL to reference the latest release version
(wasi-sdk-25).

This commit adds a browser test harness to run the tests in the browser.

## Motivation

We are heavily using wasi-libc on browsers but we don't have any test
for the case in wasi-libc. In theory, there should be no behavioral
difference between wasmtime and browsers (as long as WASI
implementations are correct) but browsers have their own limitations in
their Wasm engines. For example, memory.atomic.wait32 is not permitted
on the main thread.

We are working on adding some mitigation for such browser-specific
issues (https://github.com/WebAssembly/wasi-libc/pull/562) and this test
harness will help to validate the fix.

Rather than using Macos-latest this makes the ci used a pinned version
of Macos (set to the latest version available). This is so if you happen
to have an issue with the MacOS build you know exactly which version of
MacOS it is running, rather than having to dig into the ci, or Github
runner documentation.

Rather than using Windows-latest this PR updates the ci to use a pinned
version of Windows (set to the latest version available). This is so if
you happen to have an issue with the Windows build you know exactly
which version of Windows it is running, rather than having to dig into
the ci, or Github runner documentation.

https://github.com/llvm/llvm-project/commit/33ad474c45e6d7a0de7bc75e15e27cf6cb9ff895

This change enables the pthread-related tests in the libc-test suite.
The tests are enabled only for the `wasm32-wasip1-threads` target, which
is the only target that supports threads at the moment.

The following pthread tests are still disabled:
- pthread_cancel-points.c
- pthread_cancel.c
- pthread_robust.c

This is a preparative change for
https://github.com/swiftwasm/swift/issues/5598

Follow-up to 2b853ff0

The wrong shebang caused `&>` to be interpreted as a background job

GitHub Actions is migrating ubuntu-latest to Ubuntu 24.04, which no
longer provides the libtinfo5 package. Since older LLVM versions depend
on libtinfo5 and do not offer pre-built binaries for recent Ubuntu
versions, we explicitly specify ubuntu-22.04 in the workflow to maintain
compatibility.

https://github.com/llvm/llvm-project/commit/c3536b263f253a69fb336fb0617ee33a01a5c5dd

This change represents a rather large re-design in how `wasi-libc`
builds and runs its tests. Initially, #346 retrieved the `libc-test`
repository and built a subset of those tests to give us some amount of
test coverage. Later, because there was no way to add custom C tests,
#522 added a `smoke` directory which allowed this. But (a) each of these
test suites was built and run separately and (b) it was unclear how to
add more tests flexibly--some tests should only run on `*p2` targets or
`*-threads` targets, e.g.

This change reworks all of this so that all tests are built the same
way, in the same place. For downloaded tests like those from
`libc-test`, I chose to add "stub tests" that `#include` the original
version. This not only keeps all enabled tests in one place, it also
allows us to add "directives," C comments that the `Makefile` uses to
filter out tests for certain targets or add special compile, link or run
flags. These rudimentary scripts, along with other Bash logic I moved
out of the Makefile now live in the `scripts` directory.

Finally, all of this is explained more clearly in an updated
`README.md`. The hope with documenting this a bit better is that it
would be easier for drive-by contributors to be able to either dump in
new C tests for regressions they may find or enable more libc-tests. As
of my current count, we only enable 40/75 of libc-test's functional
tests, 0/228 math tests, 0/69 regression tests, and 0/79 API tests.
Though many of these may not apply to WASI programs, it would be nice to
explore how many more of these tests can be enabled to increase
wasi-libc's test coverage. This change should explain how to do that
and, with directives, make it possible to condition how the tests
compile and run.

This change is not meant to change any functionality, only move some
Bash-specific logic out of the `Makefile` into its own script:
`install-include-headers.sh`. This reduces the perceived complexity of
the `Makefile` but the complexity is still there, tucked away in this
script. This script also has the advantage that it can be run separately
if needed.

This commit comes after a few different attempts at building up
`Makefile` lists of headers to copy over along with the various
locations they must be copied from. It is certainly possible to do this,
but due to how we need to remove some headers from the list, it ends up
being easier to just `cp` and then `rm`, which this script retains.

This change is an effort to move all dependencies of the phony
`bindings` target into one place, for clarity.

This adds a `.stamp` file to the process of copying over the `crt` files
to the sysroot directory to avoid re-copying on each `make` invocation.

This adds a `.stamp` file to the build directory that tracks when all
headers have been copied over to the sysroot `include` directory.
Previously, the `include_dirs` target was phony, which `make` will run
every time, regardless of whether it is needed. This was part of the
problem with all of libc being rebuilt at each `make` invocation.

Previously, these were rebuilt each time as a part of the phone
`dummy_libs` target. This change only rebuilds them if they don't exist.

This updates:
- `wasi-sdk` to v24
- Wasmtime to v26.0.1
- `wasm-tools` to v1.220.0

https://github.com/llvm/llvm-project/commit/1bc2cd98c58a1059170dc38697c7a29a8e21160b

https://github.com/WebAssembly/wasi-libc/pull/522 did not include the
necessary changes to the Makefile for libc_so build.
Additionally, updated CI to check `libc_so` build too to avoid future
breakage.

~~This patch series first starts with a number of commits stubbing out
functions in the existing `THREAD_model=posix` code. According to "The
Open Group Base Specifications Issue 7, 2018 edition", there are a
number of mandatory functions which have not been provided. There are
also some optional functions that have been partially provided in a
not-useful way (e.g. get but no set function). For these, I have chosen
to clean them up and remove the get functions for consistency.~~ EDIT:
These have been split off into separate PRs and merged.

The remainder of the patches then build up a stub implementation of
pthreads for `THREAD_MODEL=single`. I have done my best to try to make
sure that all functions are as conforming as possible (under the
assumption that another thread cannot ever be launched). This means that
objects such as mutexes and rwlocks actually do update their state and
will correctly fail when locks cannot be acquired.

When an inevitable deadlock occurs, I have chosen to return EDEADLK when
it has been explicitly listed as a permissible return value, and to
invoke `__builtin_trap` otherwise.

I have tested this by rebuilding libc++ with threads enabled and then
smoke-testing Clang/LLVM-on-WASI to make sure that it can compile a
simple program. I have not run any more-extensive conformance testing.

Fixes #501

Close https://github.com/WebAssembly/wasi-libc/issues/520

Add FTS implementation derived from musl-fts with a few modifications.
The compiled fts.o is included in the libc.a archive, and the fts.h
header is installed in the sysroot (`include/fts.h`).

* fts/musl-fts: Add a copy of the musl-fts sources with modifications.
* fts/patches: A set of patches to apply to the musl-fts sources.
* Upstream pull request: https://github.com/void-linux/musl-fts/pull/14
* fts/update-musl-fts.sh: A script to update the musl-fts sources with
the patches applied.
* fts/config.h: A configuration header included by the musl-fts sources.
* test/smoke: Add a test suite for wasi-libc specific features that
libc-test does not cover.

This updates the GitHub actions to avoid errors related to deprecations;
see [this example].

[this example]:
https://github.com/WebAssembly/wasi-libc/actions/runs/10839597105/job/30080296576

Hello,

While experimenting with the `wasm32-wasip2` target and CPython, I
discovered an issue with the `getaddrinfo()` implementation: it fails to
resolve the provided service into a port number, causing `sin_port` to
always be set to 0. This issue leads to failures in network-related
functions that rely on `getaddrinfo()`, such as Python's `urllib3`
library, which passes the result directly to `connect()`. This results
in connection attempts using a port value of 0, which naturally fails.

### Minimal example to reproduce the problem
```c
#include <arpa/inet.h>
#include <netdb.h>
#include <stdio.h>

int main(void) {
    struct addrinfo *res = NULL;
    getaddrinfo("google.com", "443", NULL, &res);

    for (struct addrinfo *i = res; i != NULL; i = i->ai_next) {
        char str[INET6_ADDRSTRLEN];
        if (i->ai_addr->sa_family == AF_INET) {
            struct sockaddr_in *p = (struct sockaddr_in *)i->ai_addr;
            int port = ntohs(p->sin_port);
            printf("%s: %i\n", inet_ntop(AF_INET, &p->sin_addr, str, sizeof(str)), port);
        } else if (i->ai_addr->sa_family == AF_INET6) {
            struct sockaddr_in6 *p = (struct sockaddr_in6 *)i->ai_addr;
            int port = ntohs(p->sin6_port);
            printf("%s: %i\n", inet_ntop(AF_INET6, &p->sin6_addr, str, sizeof(str)), port);
        }
    }

    return 0;
}
```
```
$ /opt/wasi-sdk/bin/clang -target wasm32-wasip2 -o foo foo.c
$ wasmtime run -S allow-ip-name-lookup=y foo
216.58.211.238: 0
2a00:1450:4026:808::200e: 0
```
Expected output:
```
216.58.211.238: 443
2a00:1450:4026:808::200e: 443
```
### Root Cause

The root cause is that `getaddrinfo()` does not correctly translate the
provided service into a port number. As described in the `getaddrinfo()`
man [page](https://man7.org/linux/man-pages/man3/getaddrinfo.3.html),
the function should:

> service sets the port in each returned address structure. If
this argument is a service name (see
[services(5)](https://man7.org/linux/man-pages/man5/services.5.html)),
it is
translated to the corresponding port number. This argument can
also be specified as a decimal number, which is simply converted
to binary. If service is NULL, then the port number of the
returned socket addresses will be left uninitialized.

### Proposed Fix

This pull request addresses the issue by implementing the following
behavior for `getaddrinfo()`:

* If the service is `NULL`, the port number in the returned socket
addresses remains uninitialized.
* The value is converted to an integer and validated if the service is
numeric.

The PR does not currently add support for translating named services
into port numbers because `getservbyname()` has not been implemented. In
cases where a named service is provided, the `EAI_NONAME` error code is
returned.

This fixes errors like:
```
wasm-ld: error: /Volumes/PortableSSD/git/wasi-sdk/build/install/bin/../share/wasi-sysroot/lib/wasm32-wasi/llvm-lto/19.1.0-wasi-sdk/libsetjmp.a(rt.o): attempt to add bitcode file after LTO (__wasm_longjmp)
```

Note: Any symbol that the compiler might generate at bitcode compile
time either need to be unconditionally included at LTO time, or not
built as LTO. This is because LTO object files cannot be added to the
link after LTO time.