wasi: update to latest commit past sdk-22

devel/wasi-libc is now flavourised per supported LLVM version. Each
flavour includes/copies the corresponding clang's stdarg.h and
stddef.h instead of simply using the latest clang release.

Technically upstream dropped support for LLVM < 18, but the commit
doing so admittedly operated under an uncertain assumption. LLVM
17 is still supported in these ports for the benefit of Rust and
gecko@ ports, which specify LLVM 17 minimum, and to facilitate LTO
with that version. LLVM 19 is also supported in this version, with
the corresponding ports to be committed separately.

Bump PORTREVISION of consumers

devel/wasi-{compiler-rt,libcxx}: attempt to unbreak the tree

In the meta-ports, USES=llvm is defined before IGNORE, so when
DISTVERSION=0, they are marked BROKEN because LLVM version 0 is
invalid. However, the USES=llvm alone will permeate ${LLVM_DEFAULT}
unless a valid specific LLVM version/range is specified, so anything
that references the USES=llvm variables will defer to ${LLVM_DEFAULT}.
In these cases, the children of these meta-ports are split by
individual LLVM version, referencing them specifically.

Each devel/wasi-libcxx depends on the corresponding devel/wasi-compiler-rt
using ${LLVM_VERSION} through the respective meta-ports. However,
since the meta-port is not IGNOREd until after the invalid USES=llvm,
${LLVM_VERSION} is ${LLVM_DEFAULT}, which is still as of this commit
15, one of the dropped versions in WASI. BUILD_DEPENDS in the
meta-port as a result refers to a removed port, breaking the tree.

Conditionalise USES=llvm until after the proper IGNORE to avoid
this kind of situation now and into the future.

Reported by: antoine

devel/wasi-libcxx: explicitly disable LIBCXXABI_USE_LLVM_UNWINDER

LLVM 18 enables this by default, which is not wanted here. This is
effectively a no-op for other LLVM versions.

Context: https://github.com/WebAssembly/wasi-sdk/pull/377

devel/wasi-libcxx: fix PKGBASE collision

wasi: update libc to sdk-20 and modularise LLVM bits

wasi-libcxx and wasi-compiler-rt now meta ports (similar to u-boot);
the build process is the same for each LLVM version so child ports
are minimal. Minimum supported LLVM version is 12, thus its
corresponding child ports are resurrected and LLVM 11 child ports
are removed.

Since all supported LLVM versions are made available at once, remove
restriction in bsd.gecko.mk and switch to USES=llvm throughout. LTO
on gecko ports should now work with later LLVM versions so long as
${DEFAULT_VERSIONS} is set properly and matches the LLVM used in
rust (if not using the PORT_LLVM option).

Reviewed by: brooks (LLVM ports interactions)
Tested by: Eric Camachat <eric[at]camachat[dot]org>
Approved by: maintainer timeout (gecko@ portion, 2+ weeks)
PR: 274896
Differential Revision: https://reviews.freebsd.org/D40098

devel/wasi-*: take maintainership

These have to be coordinated with gecko@.

Approved by: mentors (implicit)

*/*: Release ports from maintainership

Maintainer releases all his ports.

PR:		266871
Reported by:	unrelentingtech <greg@unrelenting.technology>

Remove WWW entries moved into port Makefiles

Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.

This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.

Approved by:		portmgr (tcberner)

Add WWW entries to port Makefiles

It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.

Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.

There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.

www/firefox: unbreak after b00578b9b208

the webasm components must follow llvm (the llvm we use for building
firefox), and wasi-compiler-rt and wasi-libcxx are really just
llvm components and should be at the same version as the llvm we need.

devel/wasi-libcxx: actually disable exceptions

This port was accidentially using the base system compiler for some
parts of the configure stages - which gives wrong results in the
compiler feature tests, as base clang on FreeBSD 13.0 (llvm 11) does
not know about the wasm32 target.
Worse, even with the correct compiler some of the feature tests depend
on a present and usable libc++ for the wasi target, which we don't
have yet (this port will build one, but before...).
The end result was that the build system failed to figure out the
compiler flags for disabling exceptions (-fno-exceptions in clang's
case) and built the wasm libc++ with exceptions enabled. But exceptions
are not (yet) supported in wasi-sdk, so trying to build any code against
this wasm libc++ failed with linker errors like
  wasm-ld: error:
/usr/local/share/wasi-sysroot/lib/wasm32-wasi/libc++.a(string.cpp.o): undefined
symbol: __cxa_allocate_exception

devel/wasi-libcxx: Update to 13.0.0.

Differential Revision:	https://reviews.freebsd.org/D32441

One more small cleanup, forgotten yesterday.
Reported by:	lwhsu

Remove # $FreeBSD$ from Makefiles.

devel/wasi-compiler-rt11, wasi-libc, wasi-libcxx: New ports for WebAssembly
System Interface (WASI) libc, clang builtins (compiler-rt), libc++, libcxxabi

WASI is a "syscall" interface for WebAssembly, significantly inspired by
CloudABI.
It is supported in clang 8 and up, but to actually build C programs,
it needs clang builtins and the libc/sysroot. And for C++, also libc++ and
libcxxabi.

Submitted by:		Greg V <greg%unrelenting.technology>
Differential Revision:	https://reviews.freebsd.org/D22960