Consider adding tests for WASM support

[adamsitnik]

WASM support got again broken very recently: dotnet/runtime#78575

We should consider adding automated tests for verifying that WASM just works.

Our Linux CI jobs takes 20+ minutes to execute, so there is plenty of time we can consume (the limit is 1h).

We should mimic what we do for NativeAOT:

1. Install dependencies on Linux:
   

   BenchmarkDotNet/azure-pipelines.Ubuntu.yml

   Lines 17 to 22 in ad8e9b2

   	- bash: |
   	wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | sudo apt-key add -
   	sudo apt-add-repository "deb https://apt.llvm.org/focal/ llvm-toolchain-focal-9 main"
   	sudo apt-get update
   	- bash: |
   	sudo apt-get install cmake clang-9 libicu66 uuid-dev libcurl4-openssl-dev zlib1g-dev libkrb5-dev

   
   

   BenchmarkDotNet/.github/workflows/build.yaml

   Lines 26 to 27 in ad8e9b2

   	- name: Set up zlib-static
   	run: sudo apt-get install -y libkrb5-dev

2. Run against hardcoded version to avoid WASM breaking us.

Ideally, we should update the SDK to .NET 7 first: #2080

We don't need to build entire monoVM as described in https://benchmarkdotnet.org/articles/configs/toolchains.html#wasm. We just need to install v8 as described in https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/libraries/testing-wasm.md and follow steps described by @radical here: #1818 (comment)

cc @radical @naricc

[radical]

I think wasm tests here can avoid building the latest dotnet/runtime as you mentioned:

1. use latest dotnet 7.0
2. dotnet workload install wasm-tools --skip-manifest-update - this would allow running the tests with relinking, and AOT.
3. install v8
4. run some tests!

Essentially, the tests here will provide a basic sanity check that wasm apps can be benchmarked. In addition, the dotnet/performance repo should have similar tests but those will run some microbenchmarks from dotnet/runtime as a sanity check. And that can follow the sdk version being used by dotnet/runtime for testing.

[naricc]

@radical Do we need to rework how the wasm toolchain works? Or do we already support running it against whatever is in the the workload?

[radical]

If you are asking whether running against the workload needs to be implemented, then no, it already works, and dotnet/runtime+dotnet/performance use that.

[timcassell]

This was done in #2532.