Consider alternatives for s390x CI

[leonm1]

While implementing MODULE.bazel support for proxy-wasm-cpp-host, I ran into an issue configuring hermetic_llvm for s390x. Previously, we relied on the host toolchain for s390x, which worked because resolving toolchains_llvm was lazy and did not attempt to create a toolchain for s390x platform.

However, bazel 8+ defaults to --incompatible_enable_cc_toolchain_resolution, which means that toolchains_llvm is now eagerly evaluated by cc_library targets.

This doesn't evaluate, since llvm does not publish s390x artifacts nor does toolchains_llvm support a linux-s390x target.

There are a few other existing issues causing a large s390x CI to be a large maintenance burden:

1. github.com/chore: bump Bazel from 6.5.0 to 7.7.1 #475 required large changes to the runner to support bazel 7 for s390x
2. Bazel does not publish artifacts for s390x, so we must bootstrap and build bazel itself in the CI runner
3. The s390x runner must be qemu emulated, which makes it run orders of magnitude slower than our other runners
4. s390x is the only platform we do not use our vendored toolchain, which makes it fragile and not reproducible
5. s390x CI is not a required status check and failures do not block PR merging, which means PRs could break it even though we have a CI for it.

I'd like to capture these issues in a GH issue to evaluate whether it makes sense to continue testing each PR with s390x or whether Envoy's CI would provide sufficient coverage of the s390x platform upon updating proxy_wasm_cpp_host there.

[leonm1]

@PiotrSikora do you recall who uses proxy-wasm with the s390x architecture?

[PiotrSikora]

IBM for their Istio/Envoy based Maistra service mesh.

cc @knm3000

[leonm1]

I think that clang supports cross-compilation to s390x. If that's the case, I would not at all mind running a cross-compile job in CI and running the tests under qemu.