Purpose

The class SharedFusedMoE was proposed by @bnellnm in PR #23273. The model glm4_moe has shared experts but we don't use SharedFusedMoE for glm4_moe, I'm not sure why, please cc @bnellnm.
Let glm4_moe uses SharedFusedMoE can solve two problems in vllm-ascend:

1. All-reduce related accuracy problem. In vllm-ascend we might use different MoE strategies in different situations according to num_tokens. For example, we might use all2all-based MoE strategy when num_tokens is small and use all-gather-based MoE strategy when num_tokens is large. This means in the same vllm service we sometimes perform all-reduce of shared experts together with router experts in maybe_all_reduce_tensor_model_parallel, and sometimes perform all-reduce of shared experts independently. However in currently glm4_moe modeling, whether perform all-reduce of shared experts independently is determined for sure in init by must_reduce_shared_expert_outputs, which conficts our implemention.
2. Same as PR [Kernels] Overlap shared experts with send/recv #23273, we also want to implement our conputition-communication overlap in Ascend backend, which can easily be done with SharedFusedMoE.

In conclusion, I think we should use SharedFusedMoE to glm4_moe. cc @bnellnm @robertgshaw2-redhat @wangxiyuan @LucasWilkinson @Yikun

Test Plan

No need to add new test.

Test ResultResult

all tests should pass