[Wasi] switch to preview 2

[pavelsavara]

After this PR dotnet will produce WASM component (preview 2) instead of WASM module

• it has different binary header
• component consumes WASI imports
• it's not compatible with wasm-opt and old versions of wasm engines

Details

• switch to WASIp2 sysroot
• temporary wasi-sdk-p2.cmake file
  • to be removed when WASI SDK 23 lands
  • see add wasi-sdk-p2.cmake WebAssembly/wasi-sdk#430
• new environment variable DOTNET_WASI_PRINT_EXIT_CODE
  • will print WASM EXIT 42 into stderr when it's not zero
  • because WASI components don't return numeric exit code
  • and because our unit tests usually need to know more than 0/1
• new dotnet run option --forward-exit-code which sets it
  • the dotnet host will consume the line from stderr and return exit code to caller shell
• minor wasi cleanup
• fail fast if there is wasm-opt on PATH

WASI SDK 22 + patches

• force WASI_SDK_PATH to src\mono\wasi\wasi-sdk if the env WASI_SDK_PATH points to unpatched location
• new VERSION22PATCHED file to recognize patched installation
• new _BuildNativeEnvironmentVariables for building native libs to propagate correct WASI_SDK_PATH to shell
  Most of it could go away after update to WASI SDK 23. see [wasi] upgrade to WASI SDK with LLVM 19 #104773

Contributes to #96419
Split from #103752

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

cc @dicej, feedback welcome

[dicej]

LGTM overall. Given that some of the Bash files have changed, is one of the goals of this PR to support Linux and/or MacOS? If so, I can try building and running the smoke tests locally. Otherwise, I can fix any problems with the Linux build that pop up downstream when rebasing and testing dotnet/runtimelab#2614.

[pavelsavara]

There is #104786 and #103520 on CI

[maraf]

Changes looks good to me 👍

[pavelsavara]

LGTM overall. Given that some of the Bash files have changed, is one of the goals of this PR to support Linux and/or MacOS? If so, I can try building and running the smoke tests locally. Otherwise, I can fix any problems with the Linux build that pop up downstream when rebasing and testing dotnet/runtimelab#2614.

@dicej since I'm out next week, I will try to merge as much as possible today. I will be happy to help to upstream any of your fixes later.

Overall I think that we should consider broader set of changes from the fork. In order to make future code flow downstream easier. @SingleAccretion are there such candidates ?

[pavelsavara]

/ba-g last still running test is not relevant for this change, other CI issues are known and matched

[dicej]

@dicej since I'm out next week, I will try to merge as much as possible today. I will be happy to help to upstream any of your fixes later.

Sounds good. I'll be out the following week, but we can sync up after that. Enjoy your time off!

[SingleAccretion]

Overall I think that we should consider broader set of changes from the fork. In order to make future code flow downstream easier. @SingleAccretion are there such candidates ?

I don't think there is a lot that can be upstream (and we try to keep it that way). As you've seen in the merge, the vast majority of actual NAOT-LLVM code is concentrated in the Jit/ILC/NAOT runtime.

One thing that I would love to unify is the EMSDK layout between dotnet/emsdk and upstream EMSDK. But that's orthogonal to this WASI effort (we are, fortunately, aligned on the build system with WASI).