Move out of Alpha for Wasm Http filter

The current HTTP Wasm filter is there around 4+ years. This issue is going to track and gather info until which state we think it is reasonable to move out of alpha to `stable` based on this [extension policy](https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md#extension-stability-and-security-posture). The key point here to change the status is we want it to be security covered for critical crash bugs and not the performance improvement. And we can continue to add support to WASM and continuously support it. We already had some valuable discussion on Proxy-Wasm in #35420, here I want to focus on this specific filter.

The following items are a run from [extension policy](https://github.com/envoyproxy/envoy/blob/main/EXTENSION_POLICY.md#extension-stability-and-security-posture)

1. Does the extension have unbounded internal buffering? Does it participate in flow control via watermarking as needed?
- It is managed by the wasm to isolate the environment.
2. Does the extension have at least one deployment with live untrusted traffic for a period of time, N months?
- Istio is using Wasm
- Higress already had 40+ [Wasms](https://github.com/envoyproxy/envoy/issues/35420#issuecomment-2401190133 ).
- Many vendors already run them in prod environment.
3. Does the extension rely on dependencies that meet our [extension maturity model](https://github.com/envoyproxy/envoy/issues/10471)?
As the dependencies, we need to setup the security release and governance. There is a tool that can calculate score, we should run that and see what it identifies. We have C++ and Rust SDKs, and we can treat them separately, to state that e.g., C++ and NullVM is stable as an incremental effort.
- Proxy_wasm_cpp_host
- Proxy_wasm_cpp_sdk
- Com_google_cel_cpp
- Proxy_wasm_rust_sdk
4. Is the extension reasonable to audit by the Envoy security team?
- Yes for the filter part.
5. Is the extension free of obvious scary things, e.g. memcpy, does it have gnarly parsing code, etc?
- No
6. Does the extension have active [CODEOWNERS](https://github.com/envoyproxy/envoy/blob/main/CODEOWNERS) who are willing to vouch for the robustness of the extension?
- Yes.
7. Is the extension absent a [low coverage exception](https://github.com/envoyproxy/envoy/blob/main/test/per_file_coverage.sh#L5)?
- No, https://github.com/envoyproxy/envoy/pull/36337

Different vendors could use this extension differently, as a first step we need to improve the current status of wasm at least to move out of alpha for the implementations.

* A stable iterated ABI spec from Proxy-Wasm
- https://github.com/proxy-wasm/spec/issues/63
- https://github.com/proxy-wasm/spec/issues
- Note: the status of the extension reflects the implementation status not the ABI, we can iterate the ABI versions with more supports.
- 0.3.0 is on the way
* Security governance of `proxy-wasm-cpp-host` and `proxy-wasm-cpp-sdk` as a dependency as a start.
- scorecard: https://securityscorecards.dev/viewer/?uri=github.com/proxy-wasm/proxy-wasm-cpp-host
- https://securityscorecards.dev/viewer/?uri=github.com/proxy-wasm/proxy-wasm-cpp-sdk
* Crash [bugs](https://github.com/envoyproxy/envoy/issues?q=is%3Aissue+is%3Aopen+label%3Aarea%2Fwasm) in Envoy code from the critical data plane code.
- #36989
- #35882
- #28826
- others?
* Docs for a smooth onboard

I believe the filter itself is a shield of `wasm/common` + `Proxy-Wasm` host and SDKs and therefore is stable already IMHO. There's obviously a lot of **history** here, and I am new to this Wasm field and happy to contribute. The goal here is to create action items to reach consensus so that we can work towards it. Welcome feedback on any/all of the above points.

@mpwarres @martijneken @PiotrSikora @wbpcode @yanavlasov @kyessenov @keith @krajshiva, any thoughts?