Since AOT'ing each test suite takes between 3-9 min, we need to shift the burden over to helix.

## This is done by:
1. building the test assemblies on the build machine
   - the wasm part of the build is not executed on the build machine,
      because it has the AOT build part
2. Zip up the test assembly+friends, *and* any bits required to run the wasm
    app build for that on helix (eg. emsdk, wasm app targets, cross compiler etc)
3. Send all this to helix, and use a custom `aot-build.proj`
     - which recreates all the build inputs for the `WasmBuildApp` target
        using the paths for the assets on helix
     - then we can run `WasmBuildApp` for the build, resulting in a wasm app
       bundle.
4. Run the tests!

- We already have the bits required for building wasm apps on helix, supported
for `Wasm.Build.Tests`, which we can use here too.

## Trimming:

- Since, AOT can be so expensive, we use `EnableAggressiveTrimming=true`(EAT), but
   that means that we could have issues due to trimming.
- And it can sometimes be unclear whether the build/test failures are due to trimming
     or AOT.

- Because these builds+test runs are different from other builds, owing to the
   "build partially on helix" step, a normal EAT build would not be the same as 
- to help with testing this, we add two lanes to `runtime-staging`:
   - `*_Mono_AOT`: builds AOT+EAT on helix
   - `*_Mono_EAT`: builds EAT, on helix
      - this is required because we want to run almost the same kinda
         build: 1. build test assembly; *2. send to helix; 3. build wasm app;* 4. run tests

- This should effectively mean that we can see which errors might be due to EAT, and
   which are clearly because of EAT+AOT.
Co-authored-by: NSteve Pfister <steve.pfister@microsoft.com>
Co-authored-by: NMarek Safar <marek.safar@gmail.com>
Co-authored-by: NMitchell Hwang <mitchell.hwang@microsoft.com>
Co-authored-by: NAnkit Jain <radical@gmail.com>