Provide macros to get the WASI and WASI SDK versions

[brettcannon]

Brought up on Zulip#wasi > How to get the Wasm, WASI, & SDK version via C macros, having a way to get the compile-time values of the WASI version (e.g. 0.2) as well as the WASI SDK version (e.g. 29) would be great. I bring this up in the scope of CPython as there currently isn't a way to know these details from within CPython itself; see https://github.com/python/cpython/blob/main/Tools/wasm/README.md#detecting-webassembly-builds and how there is very little details about a WASI build compared to Emscripten.

This will also come into play when I attempt to get a Python Enhancement Proposal for wheels for WASI. There needs to be a way to get the relevant information that would be embedded in the file name#wasi > Platform tags for packages targeting WASI, and this is what's missing (__wasm32__ and __wasm64__ should be enough for CPU architecture).

[alexcrichton]

In #703 I'm proposing to use wasi/version.h as a wasi-libc-specific header file which defines __wasip{1,2,3}__. I'm not planning on just yet revealing the N in 0.2.N in the header, but that can be added in the future.

For the wasi-sdk version itself I think that's reasonable to export, but that'll require external configuration with a new cmake option. I'll work on getting that in next.

[alexcrichton]

With #709, plus future integration into wasi-sdk, this should, in theory, be resolved (unless you've got more version info you'd like out of the build)

[brettcannon]

#709 looks great as I can use __wasi_sdk_version__ and set the string in Python's sys module!

But with #703 I'm not seeing an equivalent way of getting the WASI version w/o hard-coding checks for each version via __wasipN__. That has a drawback that future versions won't be supported w/o a code change. As well, what will be used when WASI reaches 1.0? 2.0?

[alexcrichton]

Personally I'd say that's ok insofar as new WASI versions (e.g. WASIp4, WASI 1.0, etc) are major enough that code changes are warranted. They're expected to be quite rare and the only real planned one after wasip3 is WASI 1.0 without a WASI 2.0 on anyone's mind. Given that I'd personally say it's best to start a bit conservative here with as few #defines as we can get by with and then more can be added if needed over time. I don't know, for example, what we want the #define for WASI 1.0 to look like (e.g. __wasi__? __wasi1__? unsure...)

[brettcannon]

code changes are warranted.

My only concern is when a Python version reaches EOL and so might not work with newer WASI versions. Then again, that would probably require other code updates, so updating one spot isn't a big thing if it's a compiler error.

I think I just talked myself out of caring and being fine with what we got. 😁