Wasmtime's OS binary version support policy

Currently we have a number of release binaries produced as part of Wasmtime's CI and are intended to be the default way to run/use Wasmtime in a wide variety of scenarios. As a result we try to make these binaries as compatible as possible with as wide a range of OSes as we can, for example:

* Linux - these targets use glibc by default and are built in old docker containers to require as low a version of glibc as we can find
* Windows - we statically link CRT bits with `-Ctarget-feature=+crt-static` to have fewer dll dependencies
* macOS - we set `MACOS_DEPLOYMENT_TARGET` to something told to run ideally on more versions.

Otherwise though we also currently have no policy for updating these. In my experience an update inevitably breaks someone so this is mostly a desire to articulate some form of policy ahead of time of when an update is needed. This is also related to https://github.com/bytecodealliance/wasmtime/issues/10930 where I was thinking we may want to use a higher glibc requirement for a better-supported image but that's a separate issue there.

So this issue boils down to: what, if any, should Wasmtime's policy be? The defacto assumption is probably "the oldest thing that's the most compatible that we can get working", which I feel is a reasonable enough thing for macOS and Windows. For Linux it's trickier where we need to actually pick a glibc version and a distro to build in. In some sense, this issue can boil down to what our glibc versioning is.

One answer to what glibc version to use is "none" perhaps by switching to musl. That's also part of https://github.com/bytecodealliance/wasmtime/issues/10930 but while this would solve the `wasmtime` binary problem it wouldn't solve the `libwasmtime.so` problem where we'll still need to provide glibc/musl versions both.

Another possible answer is "oldest LTS we can find" which, for example, right now is Debian 11 at glibc 2.31 (as opposed to right now we're using Ubuntu 16.04 at glibc 2.23).

Do others have thoughts on this? Anyone else aware of other glibc versioning strategies that other projects are using? Should we write down more carefully what we're doing on macOS and Windows? Is this all overkill and we should just pick a reasonably old glibc?

The issue does not name specific files or tests. Start by reviewing the CI configuration and release-binary documentation for the Linux, Windows, and macOS builds. Document a policy covering supported OS versions, Linux glibc or musl choices, build environments, and when compatibility updates are appropriate.

Written by the indexing model from the issue text.