[WASI] Acquire the WASI SDK for runtime build automatically and centrally

[SingleAccretion]

I was after a few things with this change:

1. Reducing the number of places that need to be manually updated on a WASI SDK bump, i. e. getting rid of the sentinel file.
2. Decoupling the WASI SDK acquisition from the Mono build.
3. Improving ergonomics of WASI SDK acquisition (reduce manual steps required to use the repository).

All of these have been achieved with this change. See my inline comments for details.

[dotnet-policy-service]

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

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[SingleAccretion]

Well, the WASI build looks a bit better than before, but the AOT on Helix is having a hard time... Some instances of:

memory fault at wasm address 0x7568633c in linear memory of size 0x3200000

Some instances of clang OOMing.

At least the WASI SDK was transported there properly.

[pavelsavara]

Some instances of clang OOMing.

I worked this around this by #115624 for browser.
Essentially not -g for AOT builds on CI.
I will create another PR with that for WASI and consolidate those things

[maraf]

Changes look good to me 👍
We are also building WASI SDK packages, longer term question is if should migrate to it. It can then be part of WASI workload.

@pavelsavara Please provide your feedback, as you have been working on WASI more closely.

[pavelsavara]

memory fault at wasm address 0x7568633c in linear memory of size 0x3200000

I created #119299 for that

[pavelsavara]

much better than what we had so far, many thanks!

I tested it locally on windows.

[akoeplinger]

one nit, looks good otherwise

[pavelsavara]

/ba-g CI failures are unrelated